3p Enterprise Deployment on Linux

VerifiedSafe

Reference for third-party/managed deployment of Claude Desktop on Linux, covering managed-settings.json, 3p mode, inference gateways, and debugging.

Sby Skills Guide Bot
DevOpsAdvanced
7/22/2026
Claude Code
#claude-desktop#managed-settings#inference-gateway#linux#enterprise-deployment

Recommended for

Automated summary

Reference for the "3p" (third-party / enterprise / inference-gateway) deployment of Claude Desktop on Linux driven by /etc/claude-desktop/managed-settings.json: how the file is read, what 3p mode changes, which paths split, and how to verify it from logs.

Strengths

  • Documents the managed-settings.json schema precisely, including that managedMcpServers must be an array, not an object-keyed mcpServers map that the parser silently drops.
  • Explains the real effects of 3p mode — userData moving to ~/.config/Claude-3p, the hidden Chat tab, the setup SPA — and gives a clear stance on each.
  • Separates upstream behavior (the [custom-3p] log namespace) from the repository's own patches.
  • Lists the exact config keys (inferenceProvider, inferenceGatewayBaseUrl, disableDeploymentModeChooser…) and shows how to restore behavior, often via config alone.

Limitations

  • The minified names quoted are version-specific (verified against v1.14271.0) and churn on every release.
  • Assumes familiarity with managed Claude Desktop deployments and the repository's tooling (Nim patches, baseline/ION.md).
  • Linux-only; Windows/macOS paths and the old MSIX pipeline are treated as obsolete without detail.
When to use it

Use it when setting up or debugging a managed Claude Desktop deployment on Linux backed by an inference gateway, or when you need to understand 3p mode.

When not to use it

Avoid it for a standard personal-account Claude Desktop setup or for Windows/macOS deployments.

Security analysis

Safe
Quality score76/100

This is a documentation/reference skill. It contains no executable instructions, no shell pipelines, no network fetches, no obfuscated payloads, and no attempts to disable safety controls. The only 'powerful' surfaces it touches are config files and API-key field names, which it discusses anatomically rather than instructing agents to read or exfiltrate them.

Findings
  • •References privileged config paths (/etc/claude-desktop/managed-settings.json) and credential-adjacent fields (inferenceGatewayApiKey, inferenceGatewayAuthScheme) purely descriptively — no instruction to read, print, or transmit them
  • •Mentions patch files (patches/fix_marketplace_linux.nim, patches/fix_ion_dist_linux.nim) and memory keys (project_enterprise_json_schema, /linux) that are out of scope of the skill body; no code is embedded or executed
How this analysis is made

Examples

managedMcpServers ignored
I put my MCP servers under a `mcpServers` object in /etc/claude-desktop/managed-settings.json but none of them show up. Why, and what's the correct shape?
Restore the Chat tab in 3p mode
Our managed Claude Desktop deployment uses an inference gateway and the Chat tab disappeared. How do I bring it back without patching anything?
Debug the 3P setup SPA
The 3P setup window at app://localhost/setup-desktop-3p is broken in our build — walk me through fix_ion_dist_linux and fix_marketplace_linux and how to confirm it from the logs.

name: 3p description: Reference for the 3p / enterprise / inference-gateway deployment of Claude Desktop on Linux - how /etc/claude-desktop/managed-settings.json is read, what "3p mode" changes (separate ~/.config/Claude-3p userData, hidden Chat tab, the false VM-download banner), how Cowork still runs under it, which hardcoded paths are safe vs split under the -3p switch, and how to verify it all from logs. Use when working on managed-settings.json, inferenceProvider/gateway/Bedrock/Vertex configs, the 3p setup SPA (ion-dist), the Claude-3p directory, or debugging managed-deployment Cowork. when_to_use: When the user mentions managed-settings.json (or the old enterprise.json), managed/MDM config, 3p / third-party deployment, inferenceProvider (gateway/bedrock/vertex/foundry/mantle), an inference gateway / LiteLLM, the Claude-3p config dir, the "Download a one-time package" banner, deploymentMode, the 3P setup window, or edits fix_marketplace_linux / fix_ion_dist_linux. paths: patches/fix_marketplace_linux.nim, patches/fix_ion_dist_linux.nim, baseline/ION.md

3p / enterprise / inference-gateway deployment on Linux

"3p" = third-party / managed deployment: Claude Desktop pointed at a non-Anthropic inference backend (Bedrock, Vertex, Azure, or a self-hosted gateway like LiteLLM) and/or an MDM-managed config. On Linux it is driven by /etc/claude-desktop/managed-settings.json. Minified names below are version-specific (they churn every release - see /linux); anchor on stable strings. Verified against v1.14271.0.

managed-settings.json (/etc/claude-desktop/managed-settings.json)

The official Linux build reads /etc/claude-desktop/managed-settings.json natively - it ships a Linux managed-config reader, so we no longer patch the win32-registry/macOS-plist reader the way the old MSIX pipeline did. (Historical note: on the MSIX, fix_enterprise_config_linux.nim injected a Linux JSON reader for the old enterprise.json path; that patch and path are obsolete now that the official build does it.) Schema is documented in memory project_enterprise_json_schema - the load-bearing facts:

  • Top-level managedMcpServers is an array (name+transport+url/command), NOT an object-keyed mcpServers map (that is silently dropped by the schema parser - no warning).
  • Inference-gateway keys: inferenceProvider ("gateway"/"bedrock"/"vertex"/…), inferenceGatewayBaseUrl, inferenceGatewayApiKey, inferenceGatewayAuthScheme, inferenceModels (array; first is default), disableDeploymentModeChooser:true.
  • Any of inferenceProvider / bootstrapUrl present + (disableDeploymentModeChooser OR persisted deploymentMode!=="1p") flips the app into 3p mode.

What "3p mode" changes (all upstream behavior, not our patches)

| Effect | Why | Our stance | |---|---|---| | userData -> ~/.config/Claude-3p/ | Upstream setPath("userData", base+"-3p") at bootstrap, guarded by !process.env.CLAUDE_USER_DATA_DIR. Logs [custom-3p] .... | Intended - isolates 1p login from 3p. Keep it. (To collapse: export CLAUDE_USER_DATA_DIR in the launcher - it short-circuits the suffix. Not done by default.) | | Chat tab hidden | chatTabEnabled:A=>A.chatTabEnabled===!0 (strict; default off in 3p). Cowork/Code stay (!==!1). | Intended. To restore: add "chatTabEnabled": true to managed-settings.json (config-only, no patch). | | 3P setup SPA at app://localhost/setup-desktop-3p | The ion-dist config UI. | fix_ion_dist_linux + fix_marketplace_linux. Config-key schema in baseline/ION.md. |

[custom-3p] in main.log is upstream's own log namespace - do not mistake it for a patch tag.

Cowork under 3p: works the same as 1p, on the official native backend

Cowork runs on the official native Cowork VM backend bundled in the Linux .deb (cowork-linux-helper

  • QEMU/OVMF; requires /dev/kvm) - the same backend 1p uses. There is no separate daemon (the old claude-cowork-service is deprecated). The 3p OAuth bounce (issue #142 / session_stale_relogin) only fires for a genuinely broken token; a logged-in account with credits + valid Anthropic models does not bounce. (Provider model names matter: inferenceModels must be Anthropic models or the config-health gate reports config_model_rejected. A gpt-* entry, or no credits -> billing_error, makes a turn fail and looks like a bounce - it is not.)

The old "Download a one-time package" banner (getDownloadStatus() -> NotDownloaded because the local VM-image check never matched on the MSIX build) is no longer ours to patch: the official Linux build ships the native Cowork VM backend, so the historical fix_cowork_download_status_linux.nim patch is obsolete.

Does the Claude-3p split break anything? (hardcoded-path audit, verified)

No load-bearing path breaks. State isolates between Claude (1p) and Claude-3p (3p) by design; nothing crashes or cross-leaks. Rules:

  • Markers/sockets (quick-entry, SSO-callback) live in $XDG_RUNTIME_DIR (+CLAUDE_PROFILE), not .config -> unaffected by the userData switch.
  • All Electron userData (sessions, logs, claude_desktop_config.json, custom-themes JSON, screenshot restore-token) goes through app.getPath("userData"), which auto-relocates to Claude-3p. So it follows the split (e.g. a custom-theme set in 1p won't carry into 3p - cosmetic only).
  • CLI config uses CLAUDE_CONFIG_DIR (launcher); autostart .desktop files live in the XDG ~/.config/autostart/ spec dir and are CLAUDE_PROFILE-aware - both correctly not tied to the -3p userData.
  • The rule for new patches: write user state via app.getPath("userData") (auto-isolates), never a literal os.homedir()+"/.config/Claude". The Python screenshot fallback ~/.config/Claude/... in js/cu_linux_executor.js is dead code (the JS always passes the real getPath value via CLAUDE_PORTAL_TOKEN_PATH) - harmless, but don't copy that pattern.

Verify it loaded / works (logs at ~/.config/Claude-3p/logs/)

Note the dir: 3p logs to ~/.config/Claude-3p/, NOT ~/.config/Claude/. Reading the wrong dir gives stale/1p evidence.

L=~/.config/Claude-3p/logs/main.log
rg -a 'Enterprise config loaded|custom-3p\] (3P mode active|Credentials loaded|ConfigHealth)' "$L" | tail
# healthy gateway:  [custom-3p] ConfigHealth recomputed { state: 'healthy', provider: 'gateway' }
rg -a 'LocalAgentModeSessions.start|Turn succeeded|cycle_health|session_stale_relogin|config_model_rejected|billing_error' "$L" | tail
# Cowork spawn proof (official native VM backend):
rg -a 'Using Claude VM spawn|Spawn succeeded|vmStarted|Turn succeeded' ~/.config/Claude-3p/logs/cowork_vm_node.log | tail

Related

  • baseline/ION.md - 3P setup SPA bundle, patched patterns, config-key schema (inferenceProvider, deploymentOrganizationUuid, …) and the ~/.config/Claude-3p/claude_desktop_config.json path.
  • memory project_enterprise_json_schema - the exact managed-settings.json shape + how to confirm it loaded.
  • memory issue142_cowork_3p_oauth_regression - the OAuth-bounce mechanism (only bites a broken token).

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/3p-enterprise-deployment-on-linux-mrwakd6k/download' --output '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md.part' && mv '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md.part' '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md' && test -s '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/3p' && cp -R '.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k' '.claude/skills/3p'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k'

openskills read '3p-enterprise-deployment-on-linux-mrwakd6k'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/3p-enterprise-deployment-on-linux-mrwakd6k/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills