Skip to main content

Claude Code CLI

This guide explains how to deploy cx-devassist to developer machines using Claude Code's enterprise managed-settings capabilities.

Using managed settings, organizations can centrally configure Claude Code to register the Checkmarx marketplace and enable the cx-devassist plugin, so developers do not need to install the plugin or configure its marketplace manually. Managed settings can be delivered through several methods — described in Deployment Methods. Claude Code does not merge settings across methods: if more than one is present on a machine, only one takes effect.

By default, managed settings can point Claude Code directly to the official Checkmarx repository. Developers can then authenticate to Checkmarx One using either Browser sign-in (OAuth) or an API key. With browser sign-in, developers provide their Checkmarx One URL and tenant during initial authentication; these values are remembered for subsequent use. With API key authentication, the API key contains the URL and tenant information and should be distributed through your organization's approved secret-management process.

For organizations using Browser sign-in (OAuth), the Checkmarx One URL and tenant can also be preconfigured so developers do not need to enter them during initial authentication. This requires an internal fork or mirror of the Checkmarx repository, as described in Optional — Preconfigure the Checkmarx One URL and Tenant.

Important

There is no separate managed-settings field for onboarding. The Checkmarx One URL and tenant must be baked into the plugin bundle your marketplace serves — the plugin deliberately does not read onboarding values from environment variables, ~/.checkmarx, or any other out-of-tree path.

Prerequisites

Before deploying cx-devassist, ensure developer machines meet the plugin's host requirements (see README.md):

Requirement

Windows

macOS

Linux

Git for Windows (POSIX sh for hooks)

Required

—

—

Python 3

Required

Required

Required

Claude Code

Installed and managed by your organization

Same

Same

Windows: Verify that sh is available by running sh --version. If Git for Windows is installed but sh is not recognized, ensure that the Git bin directory is included in PATH.

Deployment Methods

Claude Code reads enterprise policy from the Managed scope, which takes highest precedence — users cannot override it. The same JSON configuration can be delivered through any of the following mechanisms:

Method

Platform

Location / mechanism

Native MDM

macOS

Preference domain com.anthropic.claudecode (Jamf, Kandji, etc.)

Native MDM

Windows

Registry HKLM\SOFTWARE\Policies\ClaudeCode → Settings value (REG_SZ)

File-based

macOS, Linux / WSL, Windows

System-level managed-settings.json file

Server-managed

All platforms

Anthropic admin console, or your self-hosted Claude apps gateway

These methods do not combine. If more than one delivery mechanism is present on a machine — for example, a file-based managed-settings.json and an MDM plist — only one takes effect; they are not merged. Precedence, highest to lowest:

  1. Server-managed

  2. Native MDM

  3. File-based

Choose one delivery mechanism per machine and use it consistently. Deployment steps for each method are covered in Step 2 — Deploy the Settings.

This "pick one" behavior is a deliberate design choice — methods are never layered or merged, so the effective policy on any given machine stays predictable regardless of how many delivery mechanisms your organization has configured elsewhere.

Official starter templates are available at anthropics/claude-code/examples/mdm.

Procedure

Step 1 — Configure Claude Code Managed Settings

Claude Code managed settings tell Claude Code which marketplace and plugin to make available on managed developer machines.

Configure the settings to register the official Checkmarx marketplace and enable cx-devassist:

{
  "enabledPlugins": {
    "cx-devassist@cx-devassist-marketplace": true
  },
  "extraKnownMarketplaces": {
    "cx-devassist-marketplace": {
      "source": {
        "source": "github",
        "repo": "Checkmarx/cx-agentic-ai",
        "ref": "master"
      }
    }
  }
}

This configuration:

  • extraKnownMarketplaces — Registers the Checkmarx marketplace with Claude Code. Claude Code discovers the marketplace manifest at .claude-plugin/marketplace.json when cloning a GitHub repo source.

  • enabledPlugins — Enables cx-devassist for managed users.

With this configuration, the plugin is delivered directly from the official Checkmarx repository. Developers provide their Checkmarx One URL and tenant during initial authentication.

Step 2 — Deploy the Settings

Deploy the managed settings using the one method you chose in Deployment Methods.Deployment Methods

Note: This guide describes the settings that must be deployed. The exact procedure for creating and assigning a native MDM policy depends on the MDM product used by your organization.

Native MDM

Windows (Group Policy / Intune)

Set registry key HKLM\SOFTWARE\Policies\ClaudeCode with a Settings value (REG_SZ) containing the full JSON configuration encoded as a single-line string.

See the ADMX templates at anthropics/claude-code/examples/mdm/windows.

File-based

Deploy a system-level managed-settings.json file:

OS

Path

macOS

/Library/Application Support/ClaudeCode/managed-settings.json

Linux / WSL

/etc/claude-code/managed-settings.json

Windows

C:\Program Files\ClaudeCode\managed-settings.json

Administrator or elevated permissions are required to deploy the file.

Legacy Windows path deprecated: C:\ProgramData\ClaudeCode\managed-settings.json is no longer supported as of Claude Code v2.1.75. Migrate to C:\Program Files\ClaudeCode\managed-settings.json.

Drop-in directory (optional): Claude Code also merges fragments from managed-settings.d/*.json in the same system directory, in alphabetical order, with later files overriding earlier ones. This merging happens only within the file-based method, among its own fragments — it does not merge file-based settings with MDM or server-managed settings. Use numeric prefixes (for example, 10-security.json, 20-plugins.json) to control merge order.

WSL note: On Windows, set "wslInheritsWindowsSettings": true in the HKLM managed settings if you want WSL Claude Code sessions to inherit the Windows policy chain. When set, Windows sources take priority over /etc/claude-code inside WSL.

After deploying file-based settings, developers may need to restart Claude Code or run /reload-plugins after hook script updates.

Server-managed

Configure managed settings through the Anthropic admin console, or through your self-hosted Claude apps gateway if your organization runs one. No local managed-settings file or device profile is required for machines managed this way.

Step 3 — Verify the Deployment

Verify the deployment on a test machine before rolling it out broadly.

  1. Run claude /status — setting sources should list enterprise managed settings (file, plist, or HKLM, as applicable to the method you deployed).

  2. Confirm the plugin is listed and enabled: claude plugin list should show cx-devassist@cx-devassist-marketplace ✔ enabled.

  3. Trigger first-use authentication — for example, attempt an action that hits the security gate, or run /cx-cli-setup.

  4. If authentication is required, select your organization's authentication method:

    • Browser sign-in (OAuth) — Enter the Checkmarx One URL and tenant provided by your organization, then complete authentication in the browser.

    • API key — Provide the Checkmarx One API key according to your organization's authentication process.

  5. When using Browser sign-in (OAuth), confirm the agent runs cx auth login with the pre-filled --base-auth-uri and --tenant values — the developer should not be prompted for URL or tenant.

  6. Complete login in the browser, then confirm cx auth validate succeeds.

Managed settings are read when Claude Code starts. After changing a managed-settings deployment, restart Claude Code (or run /reload-plugins for plugin/hook updates) to pick up the change.

Audit logs, if enabled, are written to:

~/.checkmarx/agent-logs/claude/cx-devassist.jsonl

Optional — Preconfigure the Checkmarx One URL and Tenant

When using Browser sign-in (OAuth), you can preconfigure the Checkmarx One URL and tenant so developers do not need to enter these values during initial authentication.

This requires maintaining an internal fork or mirror of the Checkmarx repository.

Important: With the standard deployment, the plugin is delivered directly from the official Checkmarx repository, so Checkmarx updates can be received directly. If your organization uses an internal fork or mirror to preconfigure the Checkmarx One URL and tenant, your organization administrator must keep the internal repository synchronized with updates from the official Checkmarx repository.

Step 1 — Create an Internal Fork or Mirror

  1. Fork or mirror Checkmarx/cx-agentic-ai into a repository controlled by your organization, for example YourOrg/cx-agentic-ai.

  2. Create a dedicated branch or tag for the managed deployment, for example mdm-v1 or release/mdm-2026-08.

  3. Do not point managed settings at upstream master unless you maintain that branch — upstream updates will replace your onboarding configuration.

The Claude marketplace manifest lives at .claude-plugin/marketplace.json in the repo root.

Step 2 — Configure the Checkmarx One URL and Tenant

In the internal repository, edit:

plugins/cx-devassist/config/cx-onboarding.properties

Uncomment and set both values (both are required for pre-fill to work):

cx_base_auth_uri=https://eu.ast.checkmarx.net
cx_tenant=your-org-tenant

Use the Checkmarx One base authentication URL for your region or your on-premises deployment.

You can find the tenant in Checkmarx One under Settings → Identity and Access Management → General Settings (Display Name), or in the Checkmarx One welcome email.

Value formats and common regions

Key

Format

Example

cx_base_auth_uri

https://<host>[:port] — no path, query, userinfo, or trailing slash

https://eu.ast.checkmarx.net

cx_tenant

Starts with alphanumeric; then letters, digits, ., _, - only; max 64 characters

acme-corp

Region

URL

US

https://ast.checkmarx.net

US2

https://us.ast.checkmarx.net

EU

https://eu.ast.checkmarx.net

ANZ

https://anz.ast.checkmarx.net

India

https://ind.ast.checkmarx.net

Use your on-premises URL if applicable.

If either value is missing or invalid, the plugin falls back to requesting the information from the developer rather than blocking authentication.

Commit and push the change to the branch or tag you will reference in managed settings.

Step 3 — Point Managed Settings to the Internal Repository

Update the marketplace source in the managed settings to reference the internal repository and the branch or tag used for the deployment:

{
  "enabledPlugins": {
    "cx-devassist@cx-devassist-marketplace": true
  },
  "extraKnownMarketplaces": {
    "cx-devassist-marketplace": {
      "source": {
        "source": "github",
        "repo": "YourOrg/cx-agentic-ai",
        "ref": "mdm-v1"
      }
    }
  }
}

The marketplace name can remain cx-devassist-marketplace (from .claude-plugin/marketplace.json) when using a fork — only repo and ref need to change. If you rename the marketplace in your fork's marketplace.json, update both the marketplace key and the enabledPlugins entry to match.

Claude Code's git-source marketplaces support pinning by ref (branch or tag), not by commit sha.

Step 4 — Deploy the Updated Settings

Deploy the updated managed settings through the same method described in Step 2 — Deploy the Settings.

Step 5 — Verify Preconfigured Onboarding

On a test machine:

  1. Confirm that cx-devassist is installed and enabled through managed settings (claude plugin list).

  2. Trigger first-use authentication.

  3. Select Browser sign-in (OAuth) if authentication is required.

  4. Verify that the authentication flow uses the configured Checkmarx One URL and tenant without asking the developer to provide them.

  5. Complete browser authentication, then confirm cx auth validate succeeds.

Maintain the Internal Repository

When Checkmarx publishes an updated version:

  1. Merge or cherry-pick the upstream Checkmarx changes into the internal repository.

  2. Re-apply your cx-onboarding.properties values if the merge overwrote them.

  3. Test the updated plugin on a pilot machine.

  4. Tag a new ref (for example, mdm-v2) and update the ref in managed settings if you pin by tag.

  5. Redeploy through your chosen method, or set "autoUpdate": true on the marketplace entry to let Claude Code refresh the plugin in the background after startup.

Do not edit cx-onboarding.properties directly in a developer's installed plugin directory (~/.claude/plugins/...). Installed plugin files can be overwritten during an update.

Managed enabledPlugins entries cannot be disabled through a developer's local settings. Change the managed policy to change the organization-wide plugin configuration.

Optional — Enterprise Policy Controls

Claude Code managed settings can also restrict marketplaces, plugins, MCP servers, and other Claude Code behavior. These controls are not required to deploy cx-devassist.

Restrict MCP Servers

Claude Code also supports "allowManagedMcpServersOnly": true, which restricts MCP servers to those declared in managed settings.

Because cx-devassist uses the Checkmarx MCP server, ensure any MCP allowlist used by your organization permits the Checkmarx MCP server.

If your organization does not need MCP restrictions, this setting is not required for the Checkmarx deployment.

Additional Security Controls

Claude Code managed settings provide additional controls such as "allowManagedPluginsOnly": true, which restricts installable plugins to those declared in managed settings.

Use these settings according to your organization's Claude Code security policy. They are not Checkmarx-specific requirements.

For the complete set of available controls and their syntax, see the Claude Code settings reference.

Optional — Container / CI Deployment

For container images or non-interactive environments where managed-settings file delivery is impractical, pre-populate plugins at build time using the CLAUDE_CODE_PLUGIN_SEED_DIR environment variable. See Pre-populate plugins for containers.

Combine seed directories with the same extraKnownMarketplaces / enabledPlugins values in managed settings for runtime policy. Onboarding pre-fill still comes from the plugin bundle referenced by the seed, so the internal-fork steps above still apply if you need preconfigured URL/tenant values in this environment.

API Key Authentication

API key authentication does not use cx-onboarding.properties. The API key contains the Checkmarx One URL and tenant information, so these values do not need to be preconfigured in the plugin.

If your organization uses API key authentication, distribute the Checkmarx One API key through your organization's approved secret-management process, separately from the managed-settings deployment. No onboarding file is involved.

Developers select API key as the authentication method during setup.

Troubleshooting

Symptom

Likely cause

Action

Plugin is not installed automatically

Managed settings are missing, wrong path, or invalid JSON

Verify the system path, registry key, or plist; run claude /status

strictKnownMarketplaces blocks the Checkmarx plugin

The allowlist does not match your repo/ref exactly

Add a matching entry, and also add it to extraKnownMarketplaces

Developer is prompted for URL and tenant when using the official Checkmarx repository

This is the expected first-use flow

Enter the organization's Checkmarx One URL and tenant. They are remembered for subsequent use.

Developer is prompted for URL and tenant when using a preconfigured internal repository

Onboarding file is empty, invalid, or only one key is set

Check both keys in your fork (plugins/cx-devassist/config/cx-onboarding.properties), not the live install

Wrong tenant or region at login

Stale ref or wrong values in the fork

Update the fork, bump the ref, and redeploy

Plugin update removes the pre-fill

Managed settings point at upstream instead of your fork

Point the marketplace at your internal repository and pinned ref

Hooks not loading after an update

Session cache

Run /reload-plugins or restart Claude Code

Only one delivery method appears to apply, and it's not the one you expected

Multiple methods deployed at once — Claude Code does not merge them

Remove the unwanted method, or confirm precedence (server-managed > MDM > file-based) matches your intent

WSL not picking up the Windows policy

wslInheritsWindowsSettings is not set

Add it to the HKLM managed settings on Windows

Legacy Windows path ignored

Using the deprecated ProgramData path

Migrate to C:\Program Files\ClaudeCode\managed-settings.json

Related Documentation