Skip to main content
Who this is for: Security, compliance, and IT reviewers who are assessing Claude for Government for their agency, and administrators who need to explain the product’s runtime behavior.
The answers on this page cover the Claude Desktop application in Claude for Government and address the security and data-handling questions that come up most often during agency security review. Claude Desktop offers three ways to work with Claude: Chat for simple conversations, Cowork for longer tasks with a local workspace folder, and Code for software development. Each answer states what is specific to Claude for Government (the FedRAMP High boundary, the defaults Anthropic applies for government tenants, and the relevant admin portal control), then links to the Claude Desktop documentation for the underlying mechanism. For assurance materials such as the security architecture overview, SOC 2 report, and penetration testing summary, request access through the Anthropic Trust Center.

​
Claude Desktop

The sections below cover the Claude Desktop application. For the admin portal and the Compliance API, see the Organization administration and Tenant administration sections.

​
Sandbox and isolation

In Cowork, and for the file-analysis steps in Chat, the Claude Desktop application runs shell commands and model-written code inside a dedicated local virtual machine. In Claude for Government, this sandbox is always the execution path for the code and shell commands that Claude runs in Chat and Cowork. Code sessions run on the workstation itself rather than in the virtual machine, as described under Code in Claude Desktop. For the detailed threat model and isolation design, request the security architecture overview through the Anthropic Trust Center.
The sandbox virtual machine runs the shell commands and model-written code of Cowork sessions and of the file-analysis steps in Chat. The agent loop, built-in file tools, web fetch, and the connector client run in the Claude Desktop application on the user’s device and are governed by separate controls: per-action approval prompts, administrator-set per-tool policies, and the network egress allowlist applied when each tool runs. Code sessions also run outside the virtual machine, as described under Code in Claude Desktop. For a deeper description of the layered controls inside and outside the virtual machine, see the security architecture overview available through the Anthropic Trust Center.
Shell commands that Claude runs in the sandbox work on the folders the user has attached, a scratch area, and read-only reference material bundled by the application (such as skill and plugin directories). Shell commands cannot work on the rest of the user’s files. Claude’s file-read and file-write tools are limited to those same locations and to the session’s own working folder, and they cannot read or write the rest of the user’s files unless the user adds another folder. In Cowork, Claude can ask the user to add a specific folder during the session, and the user approves or declines that request; see Approvals and Auto mode. Administrators can restrict which local folders users may attach with Allowed workspace folders on the Config page. The desktop client then refuses folders outside that list in the workspace picker, in requests Claude makes during a session, and in Claude’s file tools. See Desktop and filesystem access for how folder scoping is enforced.
When a user attaches a local folder to a Cowork session, the entire folder is made available to that session’s sandbox as a filesystem mount, so changes Claude makes are written directly to the folder on disk. A mapped network drive on Windows is an exception: Claude’s host-side file tools can read, write, and search it, but shell commands in the sandbox cannot reach network shares, so a task that runs a script or build against those files must copy them to a local folder first (see Desktop and filesystem access). Files the user attaches individually to a conversation are copied or hard-linked into a per-conversation uploads directory and mounted read-only; where the filesystem hard-links, edits to the original file while the conversation is open can be visible to it. The allowed-folders setting is a policy control enforced by the desktop application. See Desktop and filesystem access.
Some attachment types, such as Excel and PowerPoint, need a conversion step that runs inside the sandbox. Enabling Advanced file analysis in Chat under Product availability on the Config page lets Claude run code against attachments in an offline sandbox, including that conversion. You do not need to make Cowork available to get this capability. See Chat in Claude Desktop for how Chat handles file attachments.

​
Code in Claude Desktop

Code sessions use Claude Code built into the desktop application and run on the user’s workstation itself, not in the virtual machine. The shell commands Claude runs during a Code session execute on the workstation’s own operating system under the user’s own account. On macOS and Linux, those shell commands run inside an operating-system-level sandbox that the application builds from your organization’s Allowed network hosts and Allowed workspace folders settings on the Config page. The sandbox is in place whenever either setting restricts access, which the default configuration does. Inside the sandbox, a command can create or change files only in the session’s folder, the other folders Allowed workspace folders permits, and temporary locations, but the sandbox does not limit which files the command reads: it can read any file on the device that the user’s account can open, and by default it runs without asking the user first. A user can exempt specific commands from this sandbox in a Claude Code settings file, and an exempted command runs outside the sandbox under the permission mode the user selects for the session. On Linux, the sandbox requires the bubblewrap and socat packages, so install both on each workstation as described under Set up Linux and WSL2 in the Claude Code documentation. If either package is missing, shell commands run outside the sandbox as they do on Windows. On macOS and Linux, the sandbox also blocks connections to local Unix sockets. A command that talks to a local agent through a socket, such as git signing a commit with a key held in an SSH agent or a hardware-backed key manager, cannot reach that agent from inside the sandbox. On macOS, a user who needs such a command to work can list the agent’s socket path under sandbox.network.allowUnixSockets in their Claude Code settings file, which keeps the command inside the sandbox. Every sandboxed command in that user’s Code sessions can then ask the agent to sign or authenticate, so this is appropriate only for an agent that asks the user to approve each use, for example with Touch ID, and not for an agent that signs without prompting. On Linux, the sandbox ignores sandbox.network.allowUnixSockets and has no exception for individual sockets. See Sandbox settings in the Claude Code documentation. Exempting git commands such as git commit with sandbox.excludedCommands is not a safe way around the socket restriction. A sandboxed command can still change files that git runs during a commit, such as hook scripts kept in the working tree, and an exempted git commit would then run that code outside the sandbox. On macOS, git also cannot reach remotes over SSH from inside the sandbox, so a user who needs to push can use an HTTPS remote whose host is on the Allowed network hosts list, or push from a terminal outside the Code session. In container-based Linux environments, such as cloud development workspaces, the sandbox can fail to start, and shell commands in Code sessions then fail with a bwrap error. To run Code sessions there, deploy Claude Code’s own managed settings file at /etc/claude-code/managed-settings.json, set parentSettingsBehavior to "merge" in it so that your organization’s other settings for Code sessions stay in force, and add one of the two settings that follow. In that managed settings file, setting sandbox.enableWeakerNestedSandbox to true runs the sandbox in the weaker mode that Claude Code documents for containers, which keeps the network and filesystem restrictions but lets sandboxed commands see the container’s other processes. Use it only where the container already provides the isolation you need. If the sandbox still cannot start with that setting, or you prefer to rely on the container’s own controls alone, set sandbox.enabled to false instead. Shell commands then run directly in the container under the permission mode the user selects for the session, as they do on Windows, and the Allowed network hosts and Allowed workspace folders settings no longer confine what those commands can reach or change. On Windows, there is no operating-system-level sandbox for Code sessions. Shell commands run directly on the device under the permission mode the user selects for the session and under your agency’s own endpoint and network controls. The Allowed network hosts and Allowed workspace folders settings do not confine what those commands can reach, read, or change. On every operating system, the application starts a Code session only in a folder that Allowed workspace folders permits when that setting is configured, and Claude’s file reading and editing tools then work only inside the permitted folders. Administrators can also require a prompt on every shell command, in every permission mode, with the Require approval for each command sub-setting on the Shell commands card of the Config page. Code sessions in Claude for Government run on the local workstation only, and the environment options for Windows Subsystem for Linux (WSL) and SSH remote hosts are not available. Commands that belong to Claude Code’s terminal interface, such as /sandbox, are not part of Code sessions in the desktop application. See how your configuration reaches Code sessions. If your agency also deploys Claude Code’s own managed settings to the same devices, those settings take precedence over the sandbox policy described above unless they opt in to merging, as that page explains.

​
Network egress, required domains, and proxies

The desktop application and the sandbox honor the operating system’s proxy settings, and a single allowlist controls outbound network access from Claude’s tools. You manage the allowlist with the Allowed network hosts setting on the Config page.
The allowlist governs outbound network access from the shell commands and package installs of Cowork sessions, which run in the sandbox virtual machine, from the sandboxed shell commands of Code sessions on macOS and Linux (see Code in Claude Desktop), and from the host-side web fetch tool. It does not govern web search (which routes through the Claude for Government service) or connector traffic (covered under Connectors below). When the list is empty or unset, the only hosts reachable from those tools are the Claude for Government service address and, if you have set a Telemetry endpoint on the Config page, that collector’s host, which the application adds to the allowlist automatically. Package installs and page fetches to any other host fail. The list accepts exact hostnames, wildcard patterns such as *.example.com, or * to allow all outbound traffic. See Web search and web fetch for the full allowlist semantics.
For configuration and model inference, the application reaches the Claude for Government service hostname provided to your agency during onboarding. Sign-in happens in the user’s default browser, which must reach that same hostname, the Claude for Government sign-in service (a separate host that your Anthropic representative provides), and your agency’s identity provider. See the network prerequisites in Connect Claude Desktop to Claude for Government. Claude for Government does not publish IP addresses for its service and sign-in hosts, so allow both by hostname on port 443. The IP addresses page in the Claude API documentation covers the Claude API, not the Claude for Government hosts. Anthropic-bound telemetry endpoints are not contacted in Claude for Government. Allow downloads.claude.ai for the agent helper that runs Chat, Cowork, and Code sessions and for the sandbox virtual machine image, which the app fetches at session start when it does not already have them (not required if your agency uses the offline installer variant that bundles both), and www.claudeusercontent.com for the artifact preview frame. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in Telemetry and egress and confirm the update hosts for your deployment before finalizing your allowlist.
Yes. An agency that distributes Claude Desktop updates itself, for example to keep devices on an assessed version until the next one is approved, turns on Block automatic updates on the Config page and also blocks automatic updates in each device’s managed configuration, as described under Automatic updates. With both in place, the application neither downloads nor installs updates on its own. An agency that leaves automatic updates on can use Restart deadline for updates on the Config page to set how long members may postpone the restart that installs a downloaded update.
Sign-in, configuration, and model inference do not. Configuration and model inference go through the dedicated Claude for Government service hostname, and sign-in goes through that hostname, the separate Claude for Government sign-in service, and your agency’s identity provider, none of which are under either domain. Blocking *.claude.ai and *.anthropic.com leaves sign-in and inference working. Blocking *.claude.ai also blocks downloads.claude.ai, which prevents Chat conversations, Cowork tasks, and Code sessions from starting on devices installed with the standard installer unless the app has already downloaded the components they need from that host. App updates often change one or both of those components, and the sandbox virtual machine that runs shell commands in Cowork and Advanced file analysis in Chat then cannot start until the app has downloaded the new versions from that host. Devices installed with the offline installer variant, which includes those components, are not affected. Automatic application updates use hosts under these domains, so an agency that blocks these domains distributes updates itself, as described under Automatic updates.
Blocking claude.ai does not affect sign-in or inference; neither uses any host under that domain. A personal Claude account cannot sign in to Claude for Government, and a Claude for Government account cannot sign in to claude.ai, so there is no shared sign-in surface to restrict. If you allow automatic application updates, keep the update hosts listed in the network-requirements table reachable.
Yes. Every web page fetch is checked against your egress allowlist before the request is made, and redirects are re-checked against the allowlist on each hop. See Web search and web fetch. Do not rely on this allowlist alone to restrict access to your private network; see Allowed network hosts on the Config page.
Yes. Both the desktop application and the sandbox honor the operating system’s proxy settings, including PAC URLs, and route all outbound traffic through your proxy. TLS inspection at your proxy should work; validate this in your environment before rollout. See Network proxy for details. Web search requests pass through your proxy to the Claude for Government service, and the service’s onward call to the search provider originates from inside the FedRAMP High boundary.

​
Approvals and Auto mode

By default, Claude for Government prompts the user for connector actions, for each web search, and, in Cowork, when Claude asks to add another folder to the session. In Chat and Cowork, Claude’s file tools do not write outside the attached folders and the session’s working folder, as described under Sandbox and isolation. In Cowork, shell commands run without a prompt because they run inside the sandbox virtual machine. Web page fetches run without a prompt in both Chat and Cowork and are checked against the egress allowlist described above. Administrators can require a prompt on every shell command or fetch with the Require approval for each command and Require approval for each fetch sub-settings on the Config page. In Chat on Claude Desktop versions earlier than 2.110.0, every shell command prompts regardless. The reduced-approval option in Claude for Government is Auto mode, which is off by default and can be enabled through device managed configuration (it is not a setting on the Config page). Cowork does not offer a Bypass Permissions mode.
Yes. Connector actions prompt the user by default. For each connector an administrator adds, the administrator can switch individual tools on or off under Tool policy. A tool that is on stays available and each user approves every use. A tool that is off is blocked. Users cannot loosen these settings.Tools that are not listed in a connector’s Tool policy, including tools the server adds later, stay under each user’s control. The Microsoft 365 connector always asks for approval before write actions such as sending mail, changing calendar events, or posting Teams messages, and no Claude for Government setting removes that prompt. The Microsoft 365 card has no per-tool setting, and the connector’s read tools follow each user’s own approval choices. On the built-in Web search, Web fetch, and Shell commands cards of the Config page, administrators can require approval for every use or turn the tool off. See Tool and connector cards and Connectors for the available settings.
Auto mode can be disabled by policy, but not conditionally based on which connector is attached. The Auto mode policy, delivered through device managed configuration, controls whether users see Auto mode in the Cowork and Code permission selectors, and it defaults to off in Claude for Government. You can combine that policy with per-tool policies (setting a sensitive connector’s tools to ask or blocked) to achieve a similar effect.
Not in Chat or Cowork. Administrators can turn the built-in Web search, Web fetch, and Shell commands tools on or off, or require approval on every use, but cannot allowlist individual commands within those tools. In Chat, an approval for a shell command covers that one command, with no standing approval. For analyses that take many steps, Cowork runs shell commands in the sandbox without prompting; you make Cowork available to members under Product availability on the Config page. Code sessions follow Claude Code’s own permission rules, which your agency can set in a Claude Code managed-settings file. See Code in Claude Desktop.
For most tools, users who see an approval prompt can choose Always allow, which suppresses that prompt for them going forward. Administrators can remove that option on the Config page. Turning on the Require approval for each search, Require approval for each fetch, or Require approval for each command sub-setting on the Web search, Web fetch, or Shell commands card forces a fresh prompt on every use of that tool. A connector tool that an administrator has switched on under Tool policy also prompts on each use, without an Always allow choice. The Microsoft 365 connector’s read tools keep each user’s own choice, and its write actions never offer Always allow. The create-artifact prompt is an exception: it offers no standing approval. See Tool and connector cards and Connectors for the available settings.

​
Connectors

In Claude for Government, connectors fall into three main categories: built-in tools (Web search, Web fetch, and Shell commands), the built-in Microsoft 365 connector, and connectors an administrator adds on the Connectors card of the Config page.
Connectors are called from the desktop application, outside the sandbox. The built-in Microsoft 365 connector and administrator-added connectors call their endpoints directly from the user’s device, through the system proxy where one is configured. OAuth tokens for both are stored encrypted on each user’s device using operating system encryption (macOS Keychain on Mac, DPAPI on Windows). For administrator-added connectors, the bearer header entered on the Config page is delivered to each user’s desktop. A plugin package can include skills, slash commands, sub-agents, and hooks, which run on the member’s machine. The Config page asks the administrator to confirm trust before adding a plugin that declares components that can run code on the member’s machine, for example hooks or an MCP server. When an administrator adds a plugin on the Config page, Claude Desktop can run a local MCP server that the plugin declares on the member’s machine, or connect to a remote one. End users cannot add their own connectors. The Let members add plugin marketplaces and Let members add their own plugins switches on the Config page control whether end users can add plugin marketplaces or plugins of their own in Claude Desktop. Both are off by default, as described under Member-added plugins and marketplaces. A user-added plugin’s skills, slash commands, sub-agents, and hooks run on that user’s machine, and any connector it declares does not become available as an organization connector. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. See Connectors and the Plugins card under Tool and connector cards.
No. The built-in Microsoft 365 connector calls Microsoft Graph directly from the user’s device; see the Microsoft 365 connector page. Administrator-added connectors connect directly from the user’s device to the address configured for that connector. Both pass through the system proxy where one is configured. Web search is a built-in tool rather than a connector and routes through the Claude for Government service; see Web search and web fetch below.
Artifacts follow the same tool settings as Claude’s direct connector calls: a connector tool that an administrator has switched off is refused, and a tool that requires approval on every use never runs from an artifact without the user’s approval of that call. There is no single switch to disable artifact-to-connector calls while keeping connectors available to Claude directly.

​
Telemetry and logging

In Claude for Government, Anthropic-bound error and usage telemetry is always disabled. The OpenTelemetry export to your own collector is a separate setting and sends data only to the endpoint you configure.
No. Claude for Government does not include an inline content-inspection or DLP gate. The available inspection points are your own network proxy, which sees all endpoint traffic, and the desktop’s OpenTelemetry export, which sends tool-call metadata (tool name, connector, outcome, duration, and approval status) to your collector for after-the-fact review. You set the OpenTelemetry endpoint with Telemetry endpoint on the Config page. The Telemetry content capture setting on the Config page adds prompt, response, and tool content to the export for the categories you select, and nothing is selected by default. See Telemetry and egress.
Chat, Cowork, and Code sessions write a local audit log to the user’s disk recording tool invocations, permission decisions, and file operations; that log never leaves the device. The desktop can also export OpenTelemetry events to a collector you specify: tool name, connector, outcome, duration, and approval status are sent. Prompt text, Claude’s responses, and tool inputs and results are included only for the categories you select in the Telemetry content capture setting on the Config page. See Telemetry and egress for what the export can include. Server-side, the Compliance API records identity and configuration events but never tool calls or conversation content.

​
Data storage and retention

In Claude for Government, conversation content stays on the user’s device. If you select content categories in the Telemetry content capture setting on the Config page, Claude Desktop also sends the selected prompt, response, and tool content to your own OpenTelemetry collector, and never to Anthropic. Model requests are proxied through the Claude for Government service to the model endpoint inside the FedRAMP High boundary, and the service records only per-request metadata, not content.
No. Chat transcripts are stored on the user’s workstation, and the Claude for Government service does not log request or response bodies. Inference requests pass through the service to the model endpoint but are not retained. If you select content categories in the Telemetry content capture setting on the Config page, Claude Desktop also sends the selected content to your own OpenTelemetry collector, and never to Anthropic. See User identity and local data for where conversation content is stored.
Conversation content lives under the owner-only application data directory (%LOCALAPPDATA%\Claude-3p on Windows, ~/Library/Application Support/Claude-3p on macOS, ~/.config/Claude-3p on Linux). Code session transcripts live in Claude Code’s own folder in the user’s home directory (~/.claude/projects). The application does not encrypt these files itself, so encryption at rest depends on the workstation’s full-disk encryption, such as BitLocker, FileVault, or LUKS. The operating system encryption that protects connector credentials, described under Connectors, does not apply to conversation content. User-visible outputs such as artifacts are written separately to the user files directory (default ~/Claude). See User identity and local data for the full list of what each location holds.
No. Claude Desktop keeps conversation history in the application data directory of the operating system account in use on the device, and it does not divide that history by the Claude for Government organization or tenant the user signs in to. A user who is moved to another organization, or who signs in to a second tenant from the same operating system account, sees the same conversations and projects as before. Each operating system account’s application data directory is written with owner-only permissions, so other accounts on the device cannot read it, and Removing data describes how to clear it. In the folder layout that User identity and local data describes, Claude for Government uses a single fixed organization ID. The Claude Desktop configuration reference lists a deploymentOrganizationUuid key that separates local data by organization in other deployments. That key does not apply to Claude for Government, so leave it out of your configuration profile.
A project in Claude for Government is stored in the application data directory on the user’s own device, together with any instructions, links, and folder references the user adds to it. Files added to a project stay on the user’s local disk; there is no service-side project store, and files are not vectorized or indexed. Claude reads them directly from disk on demand with its file tools. A new Cowork session in the project does not reuse what an earlier session read, so Claude reads the files it needs again. The project’s memory carries short notes between sessions, such as preferences and decisions, not the contents of the files. Content Claude reads from those files is handled like the rest of the conversation: inference requests pass through the Claude for Government service to the model endpoint but are not retained. See Desktop and filesystem access.
No. The location is fixed to the per-user application data directory, and the application avoids the roaming profile because the sandbox image cache can be large. Chat history exists only on the device that created it, so back up the application data directory through your endpoint management tools if you need to preserve it. Artifacts and project folders are separate locations on the same device; see the question above. See User identity and local data for the folder layout.

​
Web search and web fetch

Web search is operated by Anthropic inside the Claude for Government FedRAMP High boundary, and the search provider’s API is the one case where traffic egresses that boundary. Before search is enabled, an administrator must acknowledge a disclosure covering this data flow when enabling the Web search card on the Config page. By default, users approve each query before it is sent, and Claude transforms it into a generic, de-identified search request and shows the user the exact text. Anthropic has a zero-data-retention agreement with the search provider. The Web search and web fetch page covers how web search is configured in other Claude Desktop deployments; the Claude for Government search path described here is specific to this deployment.
Web search is built in and does not require obtaining a separate connector. An organization owner opens the Config page, finds the Web search card, turns it on, and acknowledges the data-flow notice. The Require approval for each search setting is on by default.
Chat includes a web fetch tool, and every fetch is checked against the same egress allowlist that governs Cowork. With the allowlist empty or unset, a fetch to anything other than the Claude for Government service address (or, when configured, the Telemetry endpoint collector host) returns an error. Add hosts to Allowed network hosts on the Config page to let Chat fetch from them, or turn off the Web fetch card on the same page if you prefer Claude not to see the tool. See Web search and web fetch.

​
Chat and Cowork differences

Yes. Chat and Cowork share one list of projects, and users can start a Chat conversation or a Cowork session inside a project. A project in Claude for Government is stored only on the user’s device. There is no service-side project store, and projects are not shared between users. A Chat conversation inside a project does not gain access to the project’s folders, while Cowork sessions in a project use the same execution model as the rest of Cowork. Chat conversations in a project can read the project’s memory but cannot add to or change it. See Data storage and retention for where project contents are stored.
Yes. Artifacts are available in both Chat and Cowork. Claude creates an artifact by calling a tool when the output suits an interactive view, and the artifact opens in a side panel next to the conversation. Artifacts do not depend on the sandbox, so they remain available in Chat even when Advanced file analysis is disabled.
In Chat and Cowork, a file that Claude creates on the user’s device is in one of three places:
  • A folder the user attached to a Cowork task.
  • The working folder that each task or conversation has inside the application data directory.
  • For artifacts, the user files directory (default ~/Claude).
Files that Claude saves in a working folder appear in the conversation as file cards that the user can open or show in Finder or File Explorer and copy from there. Code sessions work directly in the folder the user opened, as described under Code in Claude Desktop.In Cowork, Claude’s file tools change files in an attached folder in place, so the changes appear there immediately. A user who wants results in a particular folder attaches that folder to the task and asks Claude to save the files there. Shell commands run inside the sandbox virtual machine, and on the device they can write only to the attached folders and the task’s working folder. A file that a command writes anywhere else in the virtual machine, for example under /tmp, does not appear in any folder on the device.By design, Chat cannot save files to other folders on the device. Claude’s file tools in Chat, and the analysis steps that run in the sandbox when Advanced file analysis in Chat is on (the default), write only to the conversation’s own working folder. For work that should end up in a particular folder, the user can run it as a Cowork task with that folder attached. See Chat in Claude Desktop for what a Chat conversation can reach, and User identity and local data for the folder layout.

​
More information

Assurance materials including the security architecture overview, SOC 2 Type 2 report, and penetration testing summary are available on request through the Anthropic Trust Center.