Skip to main content
Claude Desktop on third-party (3P) is the standard Claude Desktop application plus a managed configuration that activates third-party inference mode. Setup is two pieces: install the regular Claude Desktop app, and deliver the configuration to it.

​
System requirements

Cowork, the agent workspace at the center of Claude Desktop on 3P, has the following device requirements:
RequirementmacOSWindows
Operating systemmacOS 14 (Sonoma) or laterWindows 10 build 19041 (version 2004) or later, including Windows 11
CPU architectureApple silicon or Intel (x64)x64 or Arm64
Installer.dmg.msix
On Windows, Cowork requires the .msix package: fleets provisioned with the legacy .exe installer get Claude Desktop without Cowork, and migrating them to .msix enables it. Cowork also requires working hardware virtualization, which the readiness check verifies along with the requirements above.

​
Check device readiness

Before installing Claude Desktop, you can confirm that a device supports Cowork by running the readiness check: a small standalone program that requires no installation or sign-in.
PlatformDownload
macOSCowork readiness check for macOS
Windows (Arm)Cowork readiness check for Windows arm64
Windows (x64)Cowork readiness check for Windows x64
Open the downloaded program to run the check. A ready device reports This computer is ready for Cowork. For fleet deployments, run the check on one device of each hardware model in your fleet before the broad rollout to identify unsupported models early.

​
Install the app

Download the installer for your platform from claude.com/download.
PlatformInstallerNotes
macOS.dmgDrag Claude.app to Applications
Windows.msixSupports per-machine provisioning for enterprise deployment
For fleet rollouts, distribute the installer through your standard software-distribution mechanism after the configuration reaches devices; Choose a configuration delivery model covers how the configuration gets there.

​
Choose a configuration delivery model

Configuration reaches devices in one of two ways. Both typically use your MDM tooling to push a profile; the difference is what the profile contains.
MDM profileBootstrap server
What you deploy to devicesThe full configuration, exported as a .mobileconfig or .reg profileA minimal profile containing only the bootstrap keys (bootstrapUrl, optionally bootstrapOidc)
Where settings liveIn the profile, identical for every device the profile targetsOn an HTTPS endpoint you operate, which returns each user’s configuration at sign-in
Per-user valuesSeparate profiles per device groupThe server keys its response to the signed-in user
Changing settingsExport and push an updated profileChange your server’s response; devices pick it up at the next fetch, with no profile push
Choose an MDM profile when one configuration, or a few group-scoped profiles, covers your fleet. Most MDMs support role-based distribution, so per-group configuration doesn’t require a bootstrap server. Building the configuration in the app is optional. The in-app configuration window can also export schema-only templates (an ADMX template for Windows, a Profile Manifest .plist for macOS) from its Export menu, so you can enter values directly in your management console instead. See Export the profile for all formats. Choose a bootstrap server when your organization doesn’t use MDM, or when per-user credentials or frequently changing settings would make per-group profiles unwieldy. The tradeoff is that you operate the endpoint. The two models don’t combine: when a bootstrap response is in effect, it replaces MDM-delivered values wholesale, and a few device-level keys are only available via MDM (see the Availability column in the configuration reference). Pick your path: On either path, deploy the configuration before the app so users open Claude for the first time and land directly in the third-party deployment.

​
Single-machine setup

For evaluating before a fleet rollout, for pilots, or for organizations that don’t use MDM, a single machine can be configured directly in the app.
  1. Install Claude Desktop from claude.com/download.
  2. Launch the app. Do not sign in or create an Anthropic account. From the macOS menu bar (or on Windows, the application menu ☰ in the top-left of the login screen), go to Help → Troubleshooting → Enable Developer Mode, then Developer → Configure third-party inference to open the in-app configuration window.
  3. Enter the provider, endpoint, and credential values supplied by your administrator.
  4. Click Apply locally. The app relaunches and the sign-in screen now offers the option to start in Claude Desktop on 3P using the configuration you entered.
The configuration is written to the application’s local config file and applies only to that device and user account. It can be edited from the same window at any time. To return to standard Claude Desktop, choose the Anthropic sign-in option on the sign-in screen instead. If your organization runs a bootstrap server but doesn’t use MDM, your administrator can instead supply a small configuration file containing only the bootstrap keys. Load it with Import configuration in the same window; the bootstrap server supplies everything else after you sign in. When the configuration works on a single machine, roll it out to the fleet with the delivery model you chose; on the MDM path, you can export the tested configuration as the profile you deploy.

​
Verifying the deployment

On any configured device, open Claude Desktop and go to Help → Troubleshooting → Copy Managed Configuration Report. This copies a summary showing which keys were detected, where they were read from (managed profile vs. user store), and whether the inference credentials validated successfully. Secret values are redacted. Also confirm that the in-app configuration window (Developer → Configure third-party inference) opens read-only on a managed device. The app reads managed keys from the profile by name and silently ignores a misspelled key rather than reporting an error. On macOS, a window that is still editable means no recognized key reached the app, even if your MDM shows the profile as delivered. On Windows, even a misspelled value under HKLM\SOFTWARE\Policies\Claude counts as machine policy and locks the window, so use the Managed Configuration Report to see which keys were actually read. If your profile deliberately sets only the update keys, an editable window is expected. If the app shows the standard claude.ai sign-in screen instead of Cowork, the configuration was not read. Common causes:
  • inferenceProvider is missing, misspelled, or set to an unrecognized value
  • The configuration was applied while the app was running (fully quit and relaunch)
  • The configuration was written to the local config file but you’re checking the managed location (or vice versa)
  • A required key for the chosen provider is missing; check Help → Troubleshooting or the application log at ~/Library/Logs/Claude-3p/main.log (macOS) / %LOCALAPPDATA%\Claude-3p\Logs\main.log (Windows)
  • On Windows (v1.19367.0 and later), the configuration is in HKCU\SOFTWARE\Policies\Claude but machine policy is also present: any REG_SZ, REG_EXPAND_SZ, or REG_DWORD value directly under HKLM\SOFTWARE\Policies\Claude causes the app to ignore user policy entirely. The Managed Configuration Report (Help → Troubleshooting → Copy Managed Configuration Report) shows which source the app read. A REG_EXPAND_SZ value shows as present in reg query output while the app reports the managed configuration as invalid or absent, because the app counts the value as machine policy but cannot read its contents

​
Troubleshooting

If installation or setup fails, generate a diagnostic report before requesting support: on the affected machine, go to Help → Troubleshooting → Generate Diagnostic Report, choose a save location, and send the resulting folder to your Anthropic representative. The report contains the configuration state, application logs, and environment details needed to investigate. It does not include user data or conversation content.

​
Endpoint security software

If your organization runs binary-authorization or EDR software (such as Santa, CrowdStrike Falcon, or Microsoft Defender ASR) with path-based deny rules, the Cowork agent helper may be blocked from launching. The symptom is that Claude Desktop opens normally and reads the managed configuration, but Cowork sessions fail to start. The agent helper is a signed binary that Claude Desktop installs under its user-data directory. Allowlist by signing identity rather than path so the rule survives version updates. macOS 
~/Library/Application Support/Claude-3p/claude-code/<version>/claude.app/Contents/MacOS/claude
The helper is Developer ID signed and notarized:
  • Team ID: Q6L2SF6YDW (Anthropic PBC)
  • Signing ID: com.anthropic.claude-code
For Santa, a TEAMID allow rule for Q6L2SF6YDW covers the helper across version updates. Standard (non-3P) installs use ~/Library/Application Support/Claude/ with the same subpath. Windows 
%LOCALAPPDATA%\Claude-3p\claude-code\<version>\claude.exe
The helper is Authenticode-signed with publisher Anthropic, PBC. For Defender ASR or AppLocker, allowlist by publisher rather than path. Standard installs use %APPDATA%\Claude\ with the same subpath.

​
Offline installation

Standard installs fetch two large runtime components from downloads.claude.ai at session start: the VM workspace bundle that Cowork sessions run in, and the Claude CLI binary. For networks that cannot reach downloads.claude.ai, Anthropic publishes an offline installer variant with both components built into the installer package and verified against checksums compiled into the application, so sessions can start without any connection to Anthropic. The offline installers are several gigabytes larger than the standard ones. Each supported platform and architecture has a fixed download URL that serves the current offline installer:
PlatformFormatDownload URL
Windows (x64).msixhttps://claude.ai/api/desktop/win32/x64/offline/latest/redirect
Windows (Arm).msixhttps://claude.ai/api/desktop/win32/arm64/offline/latest/redirect
macOS (Apple silicon).dmghttps://claude.ai/api/desktop/darwin/arm64/offline/latest/redirect
macOS (Intel).dmghttps://claude.ai/api/desktop/darwin/x64/offline/latest/redirect
Each URL responds with an HTTP redirect to a versioned installer file, so any HTTP client that follows redirects downloads the installer directly. New versions of Claude Desktop roll out to connected devices gradually; these URLs serve the newest version whose rollout has completed. The redirect’s Location header contains the version number, so tooling can detect a new version by requesting the URL without following the redirect. If the offline installer for the version the URL serves is not yet available, the download fails with HTTP 404 rather than falling back to an older installer; this can happen just after a new version appears in the Location header. Keep the installer you last downloaded and retry later. Download the installer from a connected machine and bring it across your boundary with your usual software-distribution process. Pair the offline installer with disableAutoUpdates: the app cannot reach the update feed from an air-gapped network, and you update the fleet by distributing each new offline installer through your MDM. Aside from updates, the only egress an air-gapped deployment needs is your inference provider; see Telemetry and egress.

​
Updates

By default, Claude Desktop downloads updates from Anthropic’s update server automatically and applies them the next time the app restarts. If the app hasn’t restarted within 72 hours of downloading an update, it restarts itself, waiting for 10 minutes of user inactivity before doing so. This enforcement is always on and offers no in-app prompt to defer the restart; the autoUpdaterEnforcementHours key tunes the 72-hour window rather than enabling it. In 3P deployments you can:
  • Leave auto-update enabled (recommended) so fixes reach users without IT intervention. Set autoUpdaterEnforcementHours to shorten the enforcement window (1 to 72 hours; values above 72 are rejected). Setting the key also makes the window strict: the restart fires as soon as the window elapses, without waiting for a pause in user activity.
  • Disable auto-update (disableAutoUpdates) and redistribute new builds through your MDM on your own cadence. This is required for air-gapped environments but means your IT team owns the update pipeline.
See Telemetry and egress for the network paths the updater uses.