Code in Claude Desktop on 3P - Claude.ai Documentation

Code in Claude Desktop on third-party (3P) is the embedded Claude Code interface. It runs the same Claude Code engine as the standalone CLI, with a graphical session manager, and it inherits your Claude Desktop on 3P configuration automatically.

How configuration propagates

When the app starts a Code session, it translates your Claude Desktop on 3P configuration keys into the equivalent Claude Code settings and passes them to the session. You configure one profile, and Cowork and Code both honor it. Each key reaches Claude Code through one of two mechanisms, and the distinction matters if you also deploy Claude Code’s own managed settings (see the next section).

Always applied

These keys are passed directly to the Claude Code process as environment variables or launch options. They take effect on every Code session and cannot be overridden by user-level Claude Code settings or by a separately deployed managed-settings.json.

Claude Desktop on 3P key	Effect in Code sessions
`inferenceProvider` and all provider credential keys (`inferenceGateway`, `inferenceAnthropicApiKey`, `inferenceVertex`, `inferenceBedrock`, `inferenceFoundry`, `inferenceCredentialHelper*`)	Selects the inference backend and supplies credentials. Code sessions use the same provider, endpoint, and credentials as Cowork sessions.
`inferenceModels`	Populates the model picker. The first entry is the default for new Code sessions.
`autoModeEnabled`	Offers Auto mode in the Code session’s permission selector. A separately deployed Claude Code managed-settings file that sets `disableAutoMode` to `"disable"` overrides this and keeps Auto mode hidden; see below.
`disabledBuiltinTools`	Removes the listed tools from Code sessions. Tools your provider does not support, such as WebSearch on Amazon Bedrock, are removed automatically in addition to your list.
`builtinToolPolicy`	Tools set to `"ask"` require approval on each call in Code sessions, enforced via a PreToolUse hook and Claude Code `permissions.ask` rules.
`disableBypassPermissionsMode`	Removes bypass permissions mode. The app stops offering the mode and starts a session that requests it in a stricter permission mode instead, independent of Claude Code managed-settings precedence. The key requires Claude Desktop 1.46388.1 or later. A separately deployed Claude Code managed-settings file that sets `permissions.disableBypassPermissionsMode` to `"disable"` removes the mode as well.
`skipWebFetchPreflight`	Turns off Claude Code’s Web Fetch domain check against `api.anthropic.com`. A separately deployed Claude Code managed-settings file that sets `skipWebFetchPreflight` takes precedence.
`managedMcpServers`	Makes the same managed MCP servers available in Code sessions. The app handles the connection and authentication; the Code session sees only the resulting tool list.
`mcpToolTimeoutSec`	Applies your per-call MCP tool timeout to Code sessions as well, taking precedence over a user-set `MCP_TOOL_TIMEOUT`.
`organizationInstructions`	Appended to the Code session’s system prompt after Claude Code’s own. `CLAUDE.md` instructions still apply.
`otlpEndpoint`, `otlpProtocol`, `otlpHeaders`, `otlpResourceAttributes`	Routes Claude Code’s OpenTelemetry metrics and logs to your collector. See Telemetry.
`disableEssentialTelemetry`, `disableNonessentialTelemetry`	Disables Claude Code’s crash reporting and usage telemetry to Anthropic, mirroring Cowork.
`disableAutoUpdates`	The embedded Claude Code engine never self-updates regardless of this key; its version is managed by the app’s own updater.
`inferenceMaxTokensPerWindow`, `inferenceTokenWindowHours`	The token budget is shared across Cowork and Code sessions and enforced before each turn.

Applied as managed policy

These keys are translated into Claude Code managed settings and supplied to the session as policy. They take precedence over user and project settings, but they participate in Claude Code’s managed-settings precedence if you have also deployed a separate Claude Code policy.

Claude Desktop on 3P key	Claude Code policy it produces
`coworkEgressAllowedHosts`	A network sandbox restricted to your hosts plus the inference and telemetry endpoints, `WebFetch` permission rules for the same hosts, and `allowManagedDomainsOnly`.
`allowedWorkspaceFolders`	A filesystem sandbox for shell commands, which can then create or change files only inside your allowed roots and the session’s temporary locations. The sandbox does not restrict which files those commands read unless you also set `blockReadsOutsideWorkingDirectories`. The roots are also passed as `additionalDirectories` at launch, which is always applied independent of managed-settings precedence, and the app keeps Claude’s file tools inside the roots. The app also refuses to start a Code session outside an allowed root.
`blockReadsOutsideWorkingDirectories`	Claude Code’s `permissions.blockReadsOutsideWorkingDirectories` for Code sessions. Claude’s file tools refuse to read outside the working directories (the session’s folder plus your allowed roots, if any) in every permission mode. Where the sandbox from `allowedWorkspaceFolders` or `coworkEgressAllowedHosts` is running, it also hides the user’s home directory and similar locations, such as other users’ home folders and mounted volumes, from shell commands, so a sandboxed command that reads there fails without a prompt. Without a running sandbox, a shell command that reads outside the working directories, or that Claude Code cannot analyze, asks the user for approval first, even in bypass permissions mode. The key requires Claude Desktop 1.46388.1 or later. The block takes effect only in sessions that run Claude Code v2.1.257 or later; if the app cannot install its current Claude Code engine and a session runs one older than v2.1.257 that is still on the device, that session runs without the block and the app logs a warning.
`managedMcpServers`	`strictPluginOnlyCustomization` set to `["mcp"]`, so the Code session does not load MCP servers that users define on Claude Code’s side (`~/.claude.json`, a project’s `.mcp.json`, or `claude mcp add`); your managed servers, which the app connects and supplies to the session itself, and MCP servers bundled in plugins still load. When `isLocalDevMcpEnabled` is `false`, the app also sets an `allowedMcpServers` list that admits only remote servers, with `allowManagedMcpServersOnly`, so local (stdio) servers bundled in plugins from marketplaces or that users install themselves are refused, while those plugins’ remote servers still connect. Per-tool `toolPolicy` values on each server are emitted as `permissions.deny` (for `blocked`) or `permissions.ask` (for `ask`) rules against the corresponding `mcp__<server>__<tool>` names.

The network and filesystem sandboxes apply on macOS, and on Linux devices and SSH hosts with Claude Code’s sandbox dependencies installed. Claude Code does not sandbox shell commands on Windows devices, and on a Linux device or SSH host without the dependencies commands run unsandboxed with a warning in the session. In those cases, and when neither sandbox key is set, blockReadsOutsideWorkingDirectories still confines Claude’s file tools but can only ask the user to approve shell commands that read outside the working directories or that Claude Code cannot verify. Under blockReadsOutsideWorkingDirectories, sandboxed shell commands can still read system locations such as /usr, the session’s plugin and attachment folders (which become read-only), and the user’s git configuration files (~/.gitconfig and the config, ignore, and attributes files under ~/.config/git), which can themselves hold credentials such as tokens in remote URLs. Other files under the home folder outside the working directories are hidden from them, including ~/.ssh, stored git credentials, included git configuration files, signing keys, and the target of a symlinked git configuration file, so git operations that need those files fail in the session until the user re-opens the paths. In a local session Claude also cannot read a file attached or @-mentioned from outside the working directories, so users should move such files into the session’s folder or an allowed folder first. An allowed root that is or contains the home directory, such as ~ or /Users, leaves the home directory readable, so list folders below it. The block guards against content a session reads steering Claude into the user’s files, not against the user, who can re-open any path, up to their whole home folder, with sandbox.filesystem.allowRead (shell commands) or permissions.additionalDirectories (file tools and shell commands) in their own Claude Code settings, while a settings file tracked in a git repository cannot.

Interaction with Claude Code’s own managed settings

Claude Code can also be configured directly by deploying a managed-settings.json file, an OS configuration profile for Claude Code, or (with Anthropic authentication) server-managed settings. If a device has any of these, Claude Code treats it as the administrator policy and, by default, ignores the policy values Claude Desktop supplies from the Applied as managed policy table. The Always applied keys are unaffected. To have Claude Desktop’s restrictions apply on top of your Claude Code policy, set parentSettingsBehavior to "merge" in the Claude Code managed settings you deploy:

managed-settings.json

{
  "parentSettingsBehavior": "merge"
}

With "merge", Claude Desktop’s policy values are layered under your Claude Code policy. Your values win any conflict, deny and allow lists are unioned, and Claude Desktop’s values are filtered so they can only tighten policy, never loosen it. See parentSettingsBehavior in the Claude Code settings reference. Requires Claude Code v2.1.133 or later, which ships with Claude Desktop on 3P. With "merge", two Claude Code policy keys weaken blockReadsOutsideWorkingDirectories. sandbox.filesystem.allowManagedReadPathsOnly limits the block to Claude’s file tools, so a shell command that reads outside the working directories asks for approval instead of failing, and allowManagedPermissionRulesOnly removes the session’s read access to its plugin and attachment folders, so skills that read their own files stop working. Leave both out of your Claude Code policy if you rely on the block.

In a third-party deployment there is no Anthropic authentication, so Claude Code’s server-managed settings tier is never present. If you have not separately deployed a Claude Code managed-settings.json or OS profile, Claude Desktop’s policy applies automatically and you do not need to set parentSettingsBehavior.

Remote sessions over SSH

A Code session can run its Claude Code engine on a remote host over SSH while the session’s interface stays in Claude Desktop on the user’s device. In a 3P deployment this is off until you set sshHostAllowlist, because the app forwards the session’s inference credential to the host. SSH remote sessions lists the credential kinds that work on a remote host and which of the keys above apply there.

Disabling Code

To turn off Code, set isClaudeCodeForDesktopEnabled to false in your Claude Desktop on 3P configuration. Users can no longer open Code. Cowork is unaffected, and so is Chat if you have enabled it.

​How configuration propagates

​Always applied

​Applied as managed policy

​Interaction with Claude Code’s own managed settings

​Remote sessions over SSH

​Further reading

​Disabling Code

How configuration propagates

Always applied

Applied as managed policy

Interaction with Claude Code’s own managed settings

Remote sessions over SSH

Further reading

Disabling Code