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 | 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 |
Native MDM | Windows | Registry |
File-based | macOS, Linux / WSL, Windows | System-level |
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:
Server-managed
Native MDM
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.jsonwhen 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.
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 |
|
Linux / WSL |
|
Windows |
|
Administrator or elevated permissions are required to deploy the file.
Legacy Windows path deprecated:
C:\ProgramData\ClaudeCode\managed-settings.jsonis no longer supported as of Claude Code v2.1.75. Migrate toC:\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.
Run
claude /status— setting sources should list enterprise managed settings (file, plist, or HKLM, as applicable to the method you deployed).Confirm the plugin is listed and enabled:
claude plugin listshould showcx-devassist@cx-devassist-marketplace ✔ enabled.Trigger first-use authentication — for example, attempt an action that hits the security gate, or run
/cx-cli-setup.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.
When using Browser sign-in (OAuth), confirm the agent runs
cx auth loginwith the pre-filled--base-auth-uriand--tenantvalues — the developer should not be prompted for URL or tenant.Complete login in the browser, then confirm
cx auth validatesucceeds.
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
Fork or mirror
Checkmarx/cx-agentic-aiinto a repository controlled by your organization, for exampleYourOrg/cx-agentic-ai.Create a dedicated branch or tag for the managed deployment, for example
mdm-v1orrelease/mdm-2026-08.Do not point managed settings at upstream
masterunless 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 |
|---|---|---|
| | |
| Starts with alphanumeric; then letters, digits, | |
Region | URL |
|---|---|
US | |
US2 | |
EU | |
ANZ | |
India | |
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:
Confirm that cx-devassist is installed and enabled through managed settings (
claude plugin list).Trigger first-use authentication.
Select Browser sign-in (OAuth) if authentication is required.
Verify that the authentication flow uses the configured Checkmarx One URL and tenant without asking the developer to provide them.
Complete browser authentication, then confirm
cx auth validatesucceeds.
Maintain the Internal Repository
When Checkmarx publishes an updated version:
Merge or cherry-pick the upstream Checkmarx changes into the internal repository.
Re-apply your
cx-onboarding.propertiesvalues if the merge overwrote them.Test the updated plugin on a pilot machine.
Tag a new ref (for example,
mdm-v2) and update therefin managed settings if you pin by tag.Redeploy through your chosen method, or set
"autoUpdate": trueon 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 |
| The allowlist does not match your repo/ref exactly | Add a matching entry, and also add it to |
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 ( |
Wrong tenant or region at login | Stale ref or wrong values in the fork | Update the fork, bump the |
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 |
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 | | Add it to the HKLM managed settings on Windows |
Legacy Windows path ignored | Using the deprecated | Migrate to |
Related Documentation
README.md — cx-devassist overview, prerequisites, and manual installation
config/cx-onboarding.properties — onboarding configuration template and inline comments
Claude Code — settings — managed settings reference
Claude Code — plugin marketplaces — marketplace sources and managed restrictions
anthropics/claude-code/examples/mdm — Jamf, Intune, and Group Policy templates
Checkmarx One login docs — regional URLs and tenant lookup