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:44 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 18:07 UTC.
Upstream edited
Recorded here
Lines+139added
Lines−157removed
From line
14
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 14, old and new numbered
/
from line 14
1414
1515In 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](#code-in-claude-desktop). For the detailed threat model and isolation design, request the security architecture overview through the [Anthropic Trust Center](https://trust.anthropic.com).
1616
17<AccordionGroup>
18 <Accordion title="What does the sandbox isolate, and what runs outside it?">
19 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](#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](https://trust.anthropic.com).
20 </Accordion>
17> **What does the sandbox isolate, and what runs outside it?**
18>
19> 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](#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](https://trust.anthropic.com).
2120
22 <Accordion title="What can shell commands in the sandbox reach?">
23 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. 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](#approvals-and-auto-mode). Administrators can restrict which local folders users may attach with **Allowed workspace folders** on the [Config](/docs/government/config/settings#allowed-workspace-folders) 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. In Cowork, Claude's file tools may read and write in the listed folders. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
24 </Accordion>
21> **What can shell commands in the sandbox reach?**
22>
23> 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. 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](#approvals-and-auto-mode). Administrators can restrict which local folders users may attach with **Allowed workspace folders** on the [Config](/docs/government/config/settings#allowed-workspace-folders) 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. In Cowork, Claude's file tools may read and write in the listed folders. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
2524
26 <Accordion title="How are attached folders made available to the sandbox?">
27 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 can reach it only if the drive was mapped and reachable when the sandbox started (see [Network drives on Windows](/docs/third-party/claude-desktop/local-access#network-drives-on-windows)). 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](/docs/third-party/claude-desktop/local-access).
28 </Accordion>
25> **How are attached folders made available to the sandbox?**
26>
27> 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 can reach it only if the drive was mapped and reachable when the sandbox started (see [Network drives on Windows](/docs/third-party/claude-desktop/local-access#network-drives-on-windows)). 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](/docs/third-party/claude-desktop/local-access).
2928
30 <Accordion title="Which file types need the sandbox in Chat?">
31 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](/docs/government/config/settings#product-availability) page lets Claude run code against attachments in a sandbox, including that conversion. You do not need to make Cowork available to get this capability. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for how Chat handles file attachments.
32 </Accordion>
33</AccordionGroup>
29> **Which file types need the sandbox in Chat?**
30>
31> 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](/docs/government/config/settings#product-availability) page lets Claude run code against attachments in a sandbox, including that conversion. You do not need to make Cowork available to get this capability. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for how Chat handles file attachments.
3432
3533### Code in Claude Desktop
3634
from line 65
6765
6866The desktop application follows 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](/docs/government/config/settings#allowed-network-hosts) page.
6967
70<AccordionGroup>
71 <Accordion title="What does the egress allowlist control?">
72 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](#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](#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](/docs/government/config/settings#telemetry-endpoint) 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](/docs/third-party/claude-desktop/web-tools) for the full allowlist semantics.
73 </Accordion>
68> **What does the egress allowlist control?**
69>
70> 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](#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](#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](/docs/government/config/settings#telemetry-endpoint) 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](/docs/third-party/claude-desktop/web-tools) for the full allowlist semantics.
7471
75 <Accordion title="Which domains does Claude Desktop need to reach?">
76 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](/docs/government/deploy-desktop/configure#before-you-begin). 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](https://platform.claude.com/docs/en/api/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). The app also reaches the hosts listed under Non-essential services in [Required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths). If traffic is blocked, the app will run without icons, previews, and widgets. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) and confirm the update hosts for your deployment before finalizing your allowlist.
77 </Accordion>
72> **Which domains does Claude Desktop need to reach?**
73>
74> 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](/docs/government/deploy-desktop/configure#before-you-begin). 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](https://platform.claude.com/docs/en/api/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). The app also reaches the hosts listed under Non-essential services in [Required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths). If traffic is blocked, the app will run without icons, previews, and widgets. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) and confirm the update hosts for your deployment before finalizing your allowlist.
7875
79 <Accordion title="Can administrators control when Claude Desktop updates?">
80 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](/docs/government/config/settings#block-automatic-updates) page and also blocks automatic updates in each device's managed configuration, as described under [Automatic updates](/docs/government/deploy-desktop/configure#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](/docs/government/config/settings#restart-deadline-for-updates) page to set how long members may postpone the restart that installs a downloaded update.
81 </Accordion>
76> **Can administrators control when Claude Desktop updates?**
77>
78> 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](/docs/government/config/settings#block-automatic-updates) page and also blocks automatic updates in each device's managed configuration, as described under [Automatic updates](/docs/government/deploy-desktop/configure#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](/docs/government/config/settings#restart-deadline-for-updates) page to set how long members may postpone the restart that installs a downloaded update.
8279
83 <Accordion title="Does Claude for Government depend on claude.ai or anthropic.com?">
84 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](/docs/government/deploy-desktop/configure#automatic-updates).
85 </Accordion>
80> **Does Claude for Government depend on claude.ai or anthropic.com?**
81>
82> 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](/docs/government/deploy-desktop/configure#automatic-updates).
8683
87 <Accordion title="Does blocking claude.ai affect Claude for Government?">
88 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.
89 </Accordion>
84> **Does blocking claude.ai affect Claude for Government?**
85>
86> 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.
9087
91 <Accordion title="Is web fetch always checked against the allowlist?">
92 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](/docs/third-party/claude-desktop/web-tools). Do not rely on this allowlist alone to restrict access to your private network; see **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page.
93 </Accordion>
88> **Is web fetch always checked against the allowlist?**
89>
90> 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](/docs/third-party/claude-desktop/web-tools). Do not rely on this allowlist alone to restrict access to your private network; see **Allowed network hosts** on the [Config](/docs/government/config/settings#allowed-network-hosts) page.
9491
95 <Accordion title="Can all traffic route through a single proxy?">
96 Yes, with a caveat for Linux. The desktop application follows the operating system's proxy settings, including PAC URLs, and so does the Cowork sandbox on macOS and Windows. On Linux, no proxy settings reach the Cowork sandbox, and its commands connect directly. See [Network proxy](/docs/third-party/claude-desktop/network-proxy#traffic-that-bypasses-the-app-proxy) for the traffic that bypasses the proxy.
92> **Can all traffic route through a single proxy?**
93>
94> Yes, with a caveat for Linux. The desktop application follows the operating system's proxy settings, including PAC URLs, and so does the Cowork sandbox on macOS and Windows. On Linux, no proxy settings reach the Cowork sandbox, and its commands connect directly. See [Network proxy](/docs/third-party/claude-desktop/network-proxy#traffic-that-bypasses-the-app-proxy) for the traffic that bypasses the proxy.
95>
96> TLS inspection at your proxy should work; validate this in your environment before rollout. 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.
9797
98 TLS inspection at your proxy should work; validate this in your environment before rollout. 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.
99 </Accordion>
100</AccordionGroup>
101
10298### Approvals and Auto mode
10399
104100By 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, the session's working folder, [memory](/docs/third-party/claude-desktop/data-storage#memory), and the folders listed in [**Allowed workspace folders**](/docs/government/config/settings#allowed-workspace-folders). 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](#network-egress-required-domains-and-proxies). 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](/docs/government/config/settings#tool-and-connector-cards) page. In Chat on Claude Desktop versions earlier than 2.110.0, every shell command prompts regardless. By default, members cannot switch to Auto mode. When an administrator sets the **Auto mode** setting to **Allowed** on the [Config](/docs/government/config/settings#bypass-permissions-mode-and-auto-mode) page, Claude Desktop offers it in Cowork and in Code sessions, and members can switch the Claude Code command-line tool to it. New Code sessions in Claude Desktop 2.9939.2 or later and new interactive sessions in the Claude Code command-line tool 2.1.283 or later then start in it on models that support Auto mode, unless another mode is chosen. Cowork does not offer a bypass-permissions mode.
105101
106<AccordionGroup>
107 <Accordion title="Can write and send actions be gated behind approval?">
108 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.
102> **Can write and send actions be gated behind approval?**
103>
104> 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.
105>
106> 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](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
109107
110 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](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
111 </Accordion>
108> **Can Auto mode be disabled when a sensitive connector is attached?**
109>
110> Not for one connector alone. Auto mode is available only while an administrator has the **Auto mode** setting at **Allowed** on the [Config](/docs/government/config/settings#bypass-permissions-mode-and-auto-mode) page, as described above, and setting it back to **Blocked** withdraws it again. To limit a sensitive connector while Auto mode is allowed, switch the connector's tools off under **Tool policy** on the [Config](/docs/government/config/settings#tool-and-connector-cards) page.
112111
113 <Accordion title="Can Auto mode be disabled when a sensitive connector is attached?">
114 Not for one connector alone. Auto mode is available only while an administrator has the **Auto mode** setting at **Allowed** on the [Config](/docs/government/config/settings#bypass-permissions-mode-and-auto-mode) page, as described above, and setting it back to **Blocked** withdraws it again. To limit a sensitive connector while Auto mode is allowed, switch the connector's tools off under **Tool policy** on the [Config](/docs/government/config/settings#tool-and-connector-cards) page.
115 </Accordion>
112> **Can individual shell commands be allowlisted enterprise-wide?**
113>
114> 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.
116115
117 <Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
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.
119 </Accordion>
116> **Can users suppress approval prompts with an Always allow choice?**
117>
118> 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](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
120119
121 <Accordion title="Can users suppress approval prompts with an Always allow choice?">
122 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](/docs/government/config/settings#tool-and-connector-cards) and [Connectors](/docs/government/connectors/overview) for the available settings.
123 </Accordion>
124</AccordionGroup>
125
126120### Connectors
127121
128122In 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.
129123
130<AccordionGroup>
131 <Accordion title="Where do connectors run, and where are tokens stored?">
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.
124> **Where do connectors run, and where are tokens stored?**
125>
126> 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.
127>
128> 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).
129>
130> 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).
133131
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).
132> **Do connectors follow the sandbox egress allowlist?**
133>
134> No. The built-in Microsoft 365 connector calls Microsoft Graph directly from the user's device; see the [Microsoft 365 connector](/docs/government/connectors/microsoft-365) 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](#web-search-and-web-fetch) below.
135135
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).
137 </Accordion>
136> **Can artifacts be blocked from calling connectors?**
137>
138> 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.
138139
139 <Accordion title="Do connectors follow the sandbox egress allowlist?">
140 No. The built-in Microsoft 365 connector calls Microsoft Graph directly from the user's device; see the [Microsoft 365 connector](/docs/government/connectors/microsoft-365) 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](#web-search-and-web-fetch) below.
141 </Accordion>
142
143 <Accordion title="Can artifacts be blocked from calling connectors?">
144 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.
145 </Accordion>
146</AccordionGroup>
147
148140### Telemetry and logging
149141
150142In 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.
151143
152<AccordionGroup>
153 <Accordion title="Is there an inline DLP or inspection point?">
154 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 the traffic routed through it, 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](/docs/government/config/settings#telemetry-endpoint) page. The **Telemetry content capture** setting on the [Config](/docs/government/config/settings#telemetry-content-capture) 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](/docs/third-party/claude-desktop/telemetry).
155 </Accordion>
144> **Is there an inline DLP or inspection point?**
145>
146> 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 the traffic routed through it, 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](/docs/government/config/settings#telemetry-endpoint) page. The **Telemetry content capture** setting on the [Config](/docs/government/config/settings#telemetry-content-capture) 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](/docs/third-party/claude-desktop/telemetry).
156147
157 <Accordion title="What is logged for connector actions and outbound requests?">
158 Chat and Cowork 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](/docs/government/config/settings#telemetry-content-capture) page. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the export can include. Server-side, the [Compliance API](/docs/government/org-admin/compliance-api) records identity and configuration events but never tool calls or conversation content.
159 </Accordion>
160</AccordionGroup>
148> **What is logged for connector actions and outbound requests?**
149>
150> Chat and Cowork 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](/docs/government/config/settings#telemetry-content-capture) page. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the export can include. Server-side, the [Compliance API](/docs/government/org-admin/compliance-api) records identity and configuration events but never tool calls or conversation content.
161151
162152### Data storage and retention
163153
164154In 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](/docs/government/config/settings#telemetry-content-capture) 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.
165155
166<AccordionGroup>
167 <Accordion title="Can Anthropic view conversations?">
168 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](/docs/government/config/settings#telemetry-content-capture) page, Claude Desktop also sends the selected content to your own OpenTelemetry collector, and never to Anthropic. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for where conversation content is stored.
169 </Accordion>
156> **Can Anthropic view conversations?**
157>
158> 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](/docs/government/config/settings#telemetry-content-capture) page, Claude Desktop also sends the selected content to your own OpenTelemetry collector, and never to Anthropic. See [User identity and local data](/docs/third-party/claude-desktop/data-storage) for where conversation content is stored.
170159
171 <Accordion title="Where on the device is conversation content stored?">
172 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](#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](/docs/third-party/claude-desktop/data-storage) for the full list of what each location holds.
173 </Accordion>
160> **Where on the device is conversation content stored?**
161>
162> 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](#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](/docs/third-party/claude-desktop/data-storage) for the full list of what each location holds.
174163
175 <Accordion title="Is local history kept separate for each organization?">
176 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](/docs/third-party/claude-desktop/data-storage#removing-data) describes how to clear it. In the folder layout that [User identity and local data](/docs/third-party/claude-desktop/data-storage) describes, Claude for Government uses a single fixed organization ID. The Claude Desktop [configuration reference](/docs/third-party/claude-desktop/configuration#deploymentorganizationuuid) 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](/docs/government/deploy-desktop/configure#deploy-to-your-fleet).
177 </Accordion>
164> **Is local history kept separate for each organization?**
165>
166> 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](/docs/third-party/claude-desktop/data-storage#removing-data) describes how to clear it. In the folder layout that [User identity and local data](/docs/third-party/claude-desktop/data-storage) describes, Claude for Government uses a single fixed organization ID. The Claude Desktop [configuration reference](/docs/third-party/claude-desktop/configuration#deploymentorganizationuuid) 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](/docs/government/deploy-desktop/configure#deploy-to-your-fleet).
178167
179 <Accordion title="Where are files added to a project stored, and are they indexed?">
180 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](/docs/third-party/claude-desktop/data-storage#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](/docs/third-party/claude-desktop/local-access).
181 </Accordion>
168> **Where are files added to a project stored, and are they indexed?**
169>
170> 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](/docs/third-party/claude-desktop/data-storage#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](/docs/third-party/claude-desktop/local-access).
182171
183 <Accordion title="Can the local data location be changed for backup or sync?">
184 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](/docs/third-party/claude-desktop/data-storage) for the folder layout.
185 </Accordion>
186</AccordionGroup>
172> **Can the local data location be changed for backup or sync?**
173>
174> 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](/docs/third-party/claude-desktop/data-storage) for the folder layout.
187175
188176### Web search and web fetch
189177
190<AccordionGroup>
191 <Accordion title="How does web search reach the internet?">
192 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](/docs/government/config/settings#tool-and-connector-cards) 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](/docs/third-party/claude-desktop/web-tools) 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.
193 </Accordion>
178> **How does web search reach the internet?**
179>
180> 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](/docs/government/config/settings#tool-and-connector-cards) 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](/docs/third-party/claude-desktop/web-tools) 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.
194181
195 <Accordion title="How do administrators enable web search?">
196 Web search is built in and does not require obtaining a separate connector. An organization owner opens the [Config](/docs/government/config/settings#tool-and-connector-cards) 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.
197 </Accordion>
182> **How do administrators enable web search?**
183>
184> Web search is built in and does not require obtaining a separate connector. An organization owner opens the [Config](/docs/government/config/settings#tool-and-connector-cards) 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.
198185
199 <Accordion title="Why does Chat's web fetch fail with an empty allowlist?">
200 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](/docs/government/config/settings#allowed-network-hosts) 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](/docs/third-party/claude-desktop/web-tools).
201 </Accordion>
202</AccordionGroup>
186> **Why does Chat's web fetch fail with an empty allowlist?**
187>
188> 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](/docs/government/config/settings#allowed-network-hosts) 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](/docs/third-party/claude-desktop/web-tools).
203189
204190### Chat and Cowork differences
205191
206<AccordionGroup>
207 <Accordion title="Are projects available in both Chat and Cowork?">
208 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. 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](/docs/third-party/claude-desktop/data-storage#memory). See [Data storage and retention](#data-storage-and-retention) for where project contents are stored.
209 </Accordion>
192> **Are projects available in both Chat and Cowork?**
193>
194> 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. 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](/docs/third-party/claude-desktop/data-storage#memory). See [Data storage and retention](#data-storage-and-retention) for where project contents are stored.
210195
211 <Accordion title="Are artifacts available in Chat?">
212 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.
213 </Accordion>
196> **Are artifacts available in Chat?**
197>
198> 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.
214199
215 <Accordion title="Where do files that Claude creates go?">
216 In Chat and Cowork, Claude creates files on the user's device in places such as these:
200> **Where do files that Claude creates go?**
201>
202> In Chat and Cowork, Claude creates files on the user's device in places such as these:
203>
204> * A folder the user attached to a Cowork task.
205> * The working folder that each task or conversation has inside the [application data directory](#data-storage-and-retention).
206> * For artifacts, the user files directory (default `~/Claude`).
207>
208> 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](#code-in-claude-desktop).
209>
210> 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. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for what a Chat conversation can reach, and [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the folder layout.
217211
218 * A folder the user attached to a Cowork task.
219 * The working folder that each task or conversation has inside the [application data directory](#data-storage-and-retention).
220 * For artifacts, the user files directory (default `~/Claude`).
221
222 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](#code-in-claude-desktop).
223
224 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. See [Chat in Claude Desktop](/docs/third-party/claude-desktop/chat) for what a Chat conversation can reach, and [User identity and local data](/docs/third-party/claude-desktop/data-storage) for the folder layout.
225 </Accordion>
226</AccordionGroup>
227
228212## Claude Code command-line tool
229213
230214The answers below cover the standalone Claude Code command-line tool when it signs in through Claude for Government, as [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure) describes. The Claude Desktop answers above cover Code sessions inside Claude Desktop.
231215
232<AccordionGroup>
233 <Accordion title="Which domains does Claude Code need to reach?">
234 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).
235 </Accordion>
216> **Which domains does Claude Code need to reach?**
217>
218> 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).
236219
237 <Accordion title="Does Claude Code send telemetry to Anthropic?">
238 No. The managed settings in [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure#the-managed-settings) turn off Claude Code's usage telemetry and error reporting to Anthropic from the first launch, and the organization's settings keep them off after sign-in.
239 </Accordion>
240</AccordionGroup>
220> **Does Claude Code send telemetry to Anthropic?**
221>
222> No. The managed settings in [Connect Claude Code to Claude for Government](/docs/government/deploy-claude-code/configure#the-managed-settings) turn off Claude Code's usage telemetry and error reporting to Anthropic from the first launch, and the organization's settings keep them off after sign-in.
241223
242224## More information
243225
No line in this hunk matches that.