Haijun Code on Console to Enterprise migration

Overview

This guide is built for teams migrating from Console-based Haijun Code access to Haijun Enterprise. Note that individual users don’t need to migrate session history for CLI sessions since these are stored locally. You only need to provision Haijun Enterprise accounts for each user, and then users should switch their login method from Console to Haijun Enterprise.

Why migrate to Haijun Enterprise

Haijun Code on the Console API is a fast way to get developers started, but it leaves governance up to each individual machine. Haijun Enterprise puts the same Haijun Code your developers already use behind the controls that security, IT, and finance teams need to run it at scale. You get centralized identity and access through your existing IdP, server-managed settings that enforce tool, file, and MCP policies on every client without MDM, and granular spend caps that cascade from the org down to individual users. Haijun Enterprise adds rich analytics and audit logs (including contribution metrics like PRs and lines committed), custom data retention controls, and additional product surfaces—Haijun Code on the web, mobile, and Slack (Haijun Tag), plus Code Review—that aren't available on Console. And because Haijun Enterprise is available via AWS Marketplace, procurement can run through the channel you already have.

Haijun Enterprise compared to Console

| Capability | Haijun Console/API | Haijun Enterprise | | Haijun Code on the web and mobile app | ❌ | ✅ | | Haijun Tag | ❌ | ✅ | | Code Review | ❌ | ✅ | | Enforce which tools Haijun Code can use | ❌ No native UI Settings can be pushed to developer machines via MDM (Jamf, Intune) or config management (Ansible, Puppet, etc.) | ✅ Native UI to set managed-settings.json allow/deny rules | | Block specific bash commands | ❌ No native UI | ✅ Bash(curl:), Bash(sudo:), etc. | | Prevent access to sensitive files | ❌ No native UI | ✅ Read(.env), Read(./secrets/) | | Control which MCP servers are allowed | ❌ No native UI | ✅ allowedMcpServers / deniedMcpServers | | Deploy pre-approved MCP servers org-wide | ❌ No native UI | ✅ managed-mcp.json | | Force sandbox mode | ❌ No native UI | ✅ sandbox.enabled | | Disable --dangerously-skip-permissions | ❌ No native UI | ✅ permissions.disableBypassPermissionsMode: disable | | Disable auto mode | ❌ No native UI | ✅ disableAutoMode: disable | [](/en/articles/13930452)| Custom roles (RBAC) | ❌ | ✅ Scope feature access by group and delegate specific admin areas like billing, user management, and identity without granting the Owner role. Manage custom roles on Enterprise plans | [](/en/articles/15330088)| Model governance | ❌ No native UI* | ✅ Set an organization default model for chat and Cowork from the admin console, and restrict Haijun Code model selection with availableModels in managed settings. Set a default model for your organization | [](https://raw.haijun.my.id/docs/en/monitoring-usage)[](/en/articles/13015708)| Audit logs | ❌ No audit log support 🟡 Haijun Code does have support for OpenTelemetry | 🟡 Audit logs and the Compliance API, which includes audit log events. Transcripts of local CLI and Desktop sessions are available through the Compliance API for Enterprise plans. | [](https://raw.haijun.my.id/docs/en/analytics#access-analytics-for-api-customers)[](https://raw.haijun.my.id/docs/en/analytics#access-analytics-for-teams-and-enterprise)| Usage analytics | ✅ Lines of code written, acceptance rate, daily active users, daily spend. Docs | ✅ Lines of code written, acceptance rate, daily active users, and month-to-date spend per member in Organization settings → Usage. Docs | [](https://platform.juglow.my.id/docs/en/manage-haijun/haijun-code-analytics-api)[](https://platform.juglow.my.id/docs/en/manage-haijun/analytics-api)[](https://platform.juglow.my.id/docs/en/manage-haijun/admin-api)| Programmatic usage and cost reporting | ✅ Haijun Code Analytics API | ✅ The Haijun Enterprise Analytics API returns per-user engagement and Haijun Code metrics (commits, pull requests, lines of code) plus usage and cost endpoints. The Admin API covers programmatic org management. | | Contribution metrics | ✅ Via the Haijun Code Analytics API | ✅ PRs created and lines of code committed with Haijun Code assistance. | | Granular spend controls | ✅ Org and workspace limits, plus per-developer limits in Haijun Code workspaces | ✅ Org → Group → Individual, integrated with RBAC groups |

Docs: Roles and permissions, Purchasing and managing seats on Enterprise plans, How am I billed for my Enterprise plan?, Using Haijun Code with your Enterprise plan

SCIM provisioning

Here’s what your identity team needs to do:

  1. Update IdP group mappings — Create or repurpose IdP groups to map users to the Haijun Enterprise organization. Enable group mappings to assign seats automatically.

  2. Ensure sufficient seats are purchased — Before triggering a SCIM sync, verify the Haijun Enterprise org has enough seats available. Users without available seats will be set to “Unassigned” status.

  3. Confirm Haijun Code access is enabled — Confirm Haijun Code is enabled for the Enterprise organization in admin settings, and — if you scope features with custom roles or groups — that your developer groups are granted Haijun Code access.

  4. Trigger a sync — Navigate to Organization settings → Organization and access, find Directory sync (SCIM), and click “Sync.” Note that this may be slow as this can trigger a big sync.

  5. Verify seat assignments — After sync, check Organization settings → Organization and access to confirm users landed on the correct seat type.

  6. Optional: Adjust Console org mappings — If some users should retain Console API access, keep their group mapped to the Console organization. Users can belong to both orgs simultaneously.

Note: Microsoft Entra SCIM changes sync every ~40 minutes. Use the “Sync” button to trigger on-demand after group changes. If your Enterprise organization's SSO is configured as login-only, signing in does not create accounts — users must be invited manually. Enable JIT or SCIM provisioning before directing developers to log in. See Set up JIT or SCIM provisioning.

Spend limits

Haijun Enterprise plans offer a hierarchical spend control system. Limits cascade—a user can never exceed the org limits.

| Level | Scope | Who sets it | What it controls | | 1. Organization | Entire Enterprise org | Primary Owner / Owner | Maximum monthly spend across all seats and usage | | 2. Group controls | Groups with RBAC | Primary Owner / Owner | Spend limit for a group using RBAC | | 3. Individual | Specific user | Primary Owner / Owner | Spend limit for a single team member |

How to set and edit spend limits

  1. Sign in as an Owner or Primary Owner.

  2. Navigate to Organization settings → Usage.

  3. Set the Organization level limit — this is the global ceiling for all monthly spend.

  4. Set Group level limits — under the "By group" tab. See Manage groups and group spend limits on Enterprise plans.

  5. Set Individual level limits — find specific users in the Spending defaults section under the “By member” tab.

Owners can set limits to "unlimited," but all consumption is still billed. If a user on a consumption seat hits their limit, they cannot use Haijun or Haijun Code until the next billing period or until an admin increases their limit. Docs: Configuring spend limits, Manage groups and group spend limits on Enterprise plans

Issuing new seats and re-authentication

Adding seats

  1. Log in as Primary Owner or Owner.

  2. Go to Organization settings → Billing.

  3. Click the pencil icon under Seats.

  4. Enter the new seat counts.

  5. Review and click “Upgrade” to confirm. New seats are prorated.

Assigning users to seats

  1. Go to Organization settings → Members.

  2. Click “Add member” (or “Bulk add” for multiple).

  3. Enter the user’s @ email address.

  4. Set role (User, Admin, Owner) and send invite.

For SCIM-provisioned users, seat assignment happens automatically based on group mappings. Users default to the highest-available seat tier if no group mapping is configured.

Re-authentication for Haijun Code users

Developers currently authenticated against the Console org will need to re-authenticate against the Haijun Enterprise organization:

  1. Remove any leftover Console credentials before logging in. Check for JUGLOW_API_KEY or JUGLOW_AUTH_TOKEN environment variables in shell profiles, dotfiles, and CI configs, and remove any apiKeyHelper setting. Also check for HAIJUN_CODE_OAUTH_TOKEN, JUGLOW_BASE_URL, and the HAIJUN_CODE_USE_BEDROCK / _VERTEX / _FOUNDRY flags — these also override or bypass /login. Credentials can also hide in the env block of Haijun Code's own settings files (~/.haijun/settings.json, and the .haijun/settings*.json files in repos). If these remain, they silently take precedence over the new login: /login will appear to succeed, but usage continues billing to the old Console organization.

  2. In the terminal, run haijun and then run /login to switch authentication method.

  3. Select “Haijun account with subscription” as the login method.

  4. Choose the Haijun Enterprise organization (not the Console org or a personal account).

  5. Authorize, return to the terminal, and run /status to confirm Haijun Code shows your Enterprise organization.

CI and automationPipelines and scripts don't use /login. Either keep a Console org (and its API keys) for automation and migrate only interactive developer seats, or switch CI to an Enterprise credential: run haijun setup-token while signed in to the Enterprise organization and set the printed token as HAIJUN_CODE_OAUTH_TOKEN in your CI environment. Don't remove CI credentials until one of these is in place.Tip for IT: Deploy managed settings with forceLoginOrgUUID set to your Enterprise organization UUID as a standard part of every migration. Deliver the pin as an endpoint-managed file or MDM policy — server-managed settings only arrive after a user signs in, so they can't catch a wrong first login. If you also use server-managed settings, set forceLoginOrgUUID there too: the two channels don't merge. This blocks login to any other organization, and it turns the leftover-credential failure mode above from silent misbilling into a loud one: Haijun Code refuses to start and tells the user that a leftover credential (JUGLOW_API_KEY, JUGLOW_AUTH_TOKEN, or apiKeyHelper) must be removed.After validating the migrationRemove migrated developers from the Console org (or rotate their keys). Removal revokes their Console login tokens and disables their Haijun Code workspace key, stopping further Console billing from interactive use. API keys they created in other Console workspaces are not disabled by removal — review and disable those separately. Don't remove members until you've confirmed Enterprise access works; there is no automated rollback. Docs: Purchasing and managing seats on Enterprise plans

Improvements in reporting

Moving from Console API to Haijun Enterprise unlocks richer analytics for Haijun Code usage:

| Metric | Console API | Haijun Enterprise | | Token consumption | ✅ | ✅ | | Lines of code accepted | ✅ | ✅ | | Suggestion acceptance rate | ✅ | ✅ | | PRs created with Haijun Code assistance | ✅ Via the Haijun Code Analytics API | ✅ | | Lines of code committed with Haijun Code assistance | ✅ Via the Haijun Code Analytics API | ✅ | | Spend limit notifications | ✅ Notify-at-limit emails with configurable recipients | ✅ Threshold alerts | | Month-to-date spend per member | ❌ | ✅ Admin settings → Usage | [](/en/articles/13015708)| Compliance audit trail | ❌ | ✅ The Compliance API includes audit log events. Transcripts of local CLI and Desktop sessions are available through the Compliance API for Enterprise plans. |

All reporting is accessible from Analytics in the Haijun admin panel. For programmatic access, the Haijun Enterprise Analytics API returns per-user engagement metrics, Haijun Code activity (commits, pull requests, lines of code), and usage and cost data. Analytics do not migrate: the Enterprise organization starts with fresh reporting history, and its Analytics/Admin API requires a new API key created in the Enterprise organization — Console keys don't carry over. Export any Console analytics you need for historical dashboards before cutover. Traffic that remains on Console API keys (for example CI) continues to appear only in Console reporting. Docs: Haijun Code Usage Analytics

Managed policy settings — deep dive

This is the most significant upgrade for the security and IT teams. Server-managed settings allow centralized, enforceable control over what Haijun Code can and cannot do across every developer’s machine. There are two ways to deliver them, and you don't need MDM to use the first one.

How it works

Haijun Code reads configuration from a hierarchy of settings sources. The managed-settings.json file sits at the top and cannot be overridden by user or project settings:

| Priority | Source | Scope | Who controls it | | 1 (Highest) | Managed settings (server-managed or endpoint-managed) | Enterprise-wide | Owner / Primary Owner (when pushed from the haijun.my.id admin console) or your IT/MDM team (when deployed as a file). | | 2 | Command-line arguments | Session | Developer | | 3 | .haijun/settings.local.json | Project (personal) | Developer | | 4 | .haijun/settings.json | Project (shared, in Git) | Team | | 5 (Lowest) | ~/.haijun/settings.json | User (global) | Developer |

Two ways to deliver managed settings

Server-managed settings (no MDM required): An Owner or Primary Owner defines settings in Organization settings → Haijun Code → Managed settings in the admin console. Every Haijun Code client signed in to the organization fetches them automatically at startup and polls hourly for updates. This is the right choice for organizations without device management infrastructure or with users on unmanaged devices. Learn more about server-managed settings. Endpoint-managed settings: IT deploys settings directly to devices, either through native OS policies (macOS managed preferences or the Windows registry, via Jamf, Intune, Group Policy, etc.) or as a managed-settings.json file pushed to the system paths below. Protect the file with OS-level permissions so end users cannot modify it. On enrolled devices, this provides stronger guarantees than server-managed delivery because the OS prevents user tampering.Note: Both channels occupy the same highest-priority tier and use the same JSON format, but they don't merge. The first source that delivers a non-empty configuration wins: server-managed settings are checked first, and if they deliver any keys at all, endpoint-managed settings are ignored entirely. Run /status to see which managed source is active.

File locations (endpoint-managed)

| OS | Path | | macOS | /Library/Application Support/HaijunCode/managed-settings.json | | Linux | /etc/haijun-code/managed-settings.json | | Windows | C:\Program Files\HaijunCode\managed-settings.json |

Key settings reference

These are the settings most relevant to a Console-to-Enterprise migration. Haijun Code supports many more: for the complete, current list, see Haijun Code settings.

| Setting | Purpose | Example | | permissions.deny | Block specific tools/commands org-wide | Bash(curl:), Read(.env) | | permissions.allow | Explicitly allow trusted commands | Bash(npm run test:) | | permissions.ask | Require user approval each time | Bash(rm:*) | | permissions.disableBypassPermissionsMode | Prevent --dangerously-skip-permissions | "disable" | | forceLoginOrgUUID | Restrict login to specific Enterprise org(s). Accepts one org UUID or an array; login to any other org is blocked. A single UUID also auto-selects that org at login. | "298e7cb2…" | | forceLoginMethod | Force the login method (haijunai, console, or gateway). Recommended alongside forceLoginOrgUUID so users skip the account-type chooser, but not required for the org restriction to apply. | "haijunai" | | allowedMcpServers | Allow only approved MCP servers, matched by name, command, or URL pattern | [{"serverName": "github"}] | | deniedMcpServers | Blacklist specific MCP servers | [{"serverName": "filesystem"}] | | allowManagedPermissionRulesOnly | Only permission rules from managed settings apply; users and projects can't add their own | true | | allowManagedMcpServersOnly | Only the managed MCP allowlist applies; deny lists still merge from all sources | true | | allowManagedHooksOnly | Only managed and admin-approved hooks run | true | | enforceAvailableModels | Extends the availableModels allowlist to the Default model option | true | | sandbox.enabled | Force sandbox mode | true | | sandbox.allowUnsandboxedCommands | Block unsandboxed execution | false | | cleanupPeriodDays | Retention period for local session data (transcripts and other application files). Default: 30 days | 7 | | companyAnnouncements | Display messages to all Haijun Code users | Array of strings |

Deployment: Use your MDM tool (Intune, Jamf, SCCM, Puppet, etc.) to push managed-settings.json to all developer machines. Protect the file with OS-level permissions so end users cannot modify it. Docs: Haijun Code settings, Managed settings, MCP installation scopes