Security and data handling changedgovernment/security/security-and-data-handling
Nearest release: v2.1.305, published 2 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 16:30 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 16:37 UTC.
Upstream edited
Recorded here
Lines+10added
Lines−4removed
From line
38
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits26to this page, all time
The whole hunk
from line 38, old and new numbered
/
from line 38
3838
3939On 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](/docs/government/config/settings#allowed-network-hosts) 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. Unless [**Block reads outside workspace folders**](/docs/government/config/settings#block-reads-outside-workspace-folders) is on, it can read any file on the device that the user's account can open. 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.
4040
41Claude can also type commands into the Code tab's terminal, which is the user's own shell (PowerShell on Windows). The app asks the user to approve each of those commands by default, and they run as the user, outside any sandbox. Administrators can turn these terminal tools off with the **Terminal panel tools** card on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. The [**Blocked shell commands**](/docs/government/config/settings#claude-code) list does not block commands Claude types into the terminal, but the **Require approval for each command** sub-setting on the **Shell commands** card applies to them in every permission mode.
42
4143On Linux, the sandbox requires the `bubblewrap` and `socat` packages, so install both on each workstation as described under [Set up Linux and WSL2](https://code.claude.com/docs/en/sandboxing#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.
4244
4345On 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.
from line 115
113115 </Accordion>
114116
115117 <Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
116 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](/docs/government/config/settings#product-availability) page. In Code sessions, the [Claude Code](/docs/government/config/settings#claude-code) section has no setting that allows individual commands. Permission rules in a Claude Code managed-settings file on the device can allow individual commands, but they apply in Code sessions only where your organization's Claude Code settings don't reach them, as [Code in Claude Desktop](#code-in-claude-desktop) describes.
118 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](/docs/government/config/settings#product-availability) page. In Code sessions, the [Claude Code](/docs/government/config/settings#claude-code) section has no list of allowed commands. Permission rules in a Claude Code managed-settings file on the device can allow individual commands, but they apply in Code sessions only where your organization's Claude Code settings don't reach them, as [Code in Claude Desktop](#code-in-claude-desktop) describes.
117119 </Accordion>
118120
119121 <Accordion title="Can users suppress approval prompts with an Always allow choice?">
from line 125
123125
124126### Connectors
125127
126In 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](/docs/government/config/settings#tool-and-connector-cards) page.
128In Claude for Government, connectors fall into three main categories: built-in tools (Web search, Web fetch, Shell commands, and Terminal panel tools), the built-in Microsoft 365 connector, and connectors an administrator adds on the Connectors card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.
127129
128130<AccordionGroup>
129131 <Accordion title="Where do connectors run, and where are tokens stored?">
130 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. The **Let members add their own connectors** switch on the Config page controls whether end users can add local MCP servers of their own in Claude Desktop, under **Settings**, then **Developer**. It is off by default, as described under [Let members add their own connectors](/docs/government/config/settings#let-members-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](/docs/government/config/settings#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](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
132 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.
133
134 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. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. The **Let members add their own connectors** switch on the Config page controls whether end users can add local MCP servers of their own in Claude Desktop, under **Settings**, then **Developer**. It is off by default, as described under [Let members add their own connectors](/docs/government/config/settings#let-members-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](/docs/government/config/settings#member-added-plugins-and-marketplaces).
135
136 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. Hook commands and local MCP servers run as programs under the user's own account, outside both the [sandbox virtual machine](#sandbox-and-isolation) and the [Code session sandbox](#code-in-claude-desktop). See [Connectors](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
131137 </Accordion>
132138
133139 <Accordion title="Do connectors follow the sandbox egress allowlist?">
from line 233
227233
228234<AccordionGroup>
229235 <Accordion title="Which domains does Claude Code need to reach?">
230 The Claude for Government gateway address that your Anthropic representative provides, over HTTPS on port 443, for sign-in, organization settings, and model inference. Sign-in finishes in the user's browser, which needs the Claude for Government host, its sign-in service, and your agency's identity provider, as for Claude Desktop. Claude Code also reaches, from the user's device, the address of each connector an administrator applies to **Claude Code** on the **Connectors** card, and that connector's sign-in service when it uses OAuth. The managed settings from [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure#before-sign-in) turn off Claude Code's background connections before sign-in (release notes, update checks, and the official plugin marketplace).
236 The Claude for Government gateway address in the managed settings from [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure#the-managed-settings), over HTTPS on port 443, for sign-in, organization settings, and model inference. Sign-in finishes in the user's browser, which needs the Claude for Government host, its sign-in service, and your agency's identity provider, as for Claude Desktop. Claude Code also reaches, from the user's device, the address of each connector an administrator applies to **Claude Code** on the **Connectors** card, and that connector's sign-in service when it uses OAuth. The managed settings from [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure#before-sign-in) turn off Claude Code's background connections before sign-in (release notes, update checks, and the official plugin marketplace).
231237 </Accordion>
232238
233239 <Accordion title="Does Claude Code send telemetry to Anthropic?">
No line in this hunk matches that.