Security and data handling changedgovernment/security/security-and-data-handling
Nearest release: v2.1.267, published 2 hours before this site recorded the change. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Recorded here
Lines+23added
Lines−7removed
From line
20
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 20, old and new numbered
/
from line 20
2020 </Accordion>
2121
2222 <Accordion title="What can the sandbox reach on the host?">
23 The sandbox sees the workspace folders the user has attached to the session, its own scratch area, and read-only reference material bundled by the application (such as skill and plugin directories). It does not see the rest of the user's filesystem. File-read and file-write tools default to those same attached folders, and prompt the user before reading or writing outside them; 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 both the workspace picker and Claude's file tools. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
23 The sandbox sees the workspace folders the user has attached to the session, its own scratch area, and read-only reference material bundled by the application (such as skill and plugin directories). It does not see the rest of the user's filesystem. 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](#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. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access) for how folder scoping is enforced.
2424 </Accordion>
2525
2626 <Accordion title="How are attached folders made available to the sandbox?">
from line 84
8484
8585### Approvals and Auto mode
8686
87By default, Claude for Government prompts the user for file writes outside the attached workspace, connector actions, and each web search. 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** sub-settings on the [Config](/docs/government/config/settings#tool-and-connector-cards) page. In Chat, 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.
87By 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](#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](/docs/government/config/settings#tool-and-connector-cards) page. In Chat, 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.
8888
8989<AccordionGroup>
9090 <Accordion title="Can write and send actions be gated behind approval?">
91 Yes. Administrators can set each built-in and connector tool to **ask** (approval required on every call), **allow** (pre-approved), or **blocked** (removed entirely), and users cannot override those settings. For the Microsoft 365 connector, certain irreversible write tools (sending or forwarding mail, and creating or updating calendar events) are fixed to **ask** and cannot be changed to **allow**. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the per-tool policy options.
91 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.
92
93 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.
9294 </Accordion>
9395
9496 <Accordion title="Can Auto mode be disabled when a sensitive connector is attached?">
from line 98
9698 </Accordion>
9799
98100 <Accordion title="Can individual shell commands be allowlisted enterprise-wide?">
99 No. Policy controls whole tools (shell, file read, web fetch, and so on) but not individual commands within a tool. In Chat, each shell command prompts the user 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.
101 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, each shell command prompts the user 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. 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](#code-in-claude-desktop).
100102 </Accordion>
101103
102104 <Accordion title="Can users suppress approval prompts with an Always allow choice?">
103 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 by setting the tool's policy to **ask**, which forces a fresh prompt on every call. The create-artifact prompt and code execution in Chat are exceptions: neither offers a standing approval. See the [Configuration reference](/docs/third-party/claude-desktop/configuration) for the full tool-policy options.
105 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 and code execution in Chat are exceptions: neither offers a 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.
104106 </Accordion>
105107
106108 <Accordion title="Why does Chat prompt on every analysis step?">
from line 124
122124 </Accordion>
123125
124126 <Accordion title="Can artifacts be blocked from calling connectors?">
125 Artifacts honor the same per-tool approval policy as Claude's direct connector calls: tools set to **blocked** are refused and tools set to **ask** require user confirmation. There is no single switch to disable artifact-to-connector calls while keeping connectors available to Claude directly.
127 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.
126128 </Accordion>
127129</AccordionGroup>
128130
from line 152
150152 </Accordion>
151153
152154 <Accordion title="Where on the device is conversation content stored?">
153 Conversation content lives under the owner-only application data directory (`%LOCALAPPDATA%\Claude-3p` on Windows, `~/Library/Application Support/Claude-3p` on macOS). 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.
155 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.
154156 </Accordion>
155157
156158 <Accordion title="Is local history kept separate for each organization?">
from line 193
191193
192194 <Accordion title="Are artifacts available in Chat?">
193195 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.
196 </Accordion>
197
198 <Accordion title="Where do files that Claude creates go?">
199 In Chat and Cowork, a file that Claude creates on the user's device is in one of three places:
200
201 * A folder the user attached to a Cowork task.
202 * The working folder that each task or conversation has inside the [application data directory](#data-storage-and-retention).
203 * For artifacts, the user files directory (default `~/Claude`).
204
205 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).
206
207 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 the only writable locations it shares with the device are 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.
208
209 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](/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.
194210 </Accordion>
195211</AccordionGroup>
196212
No line in this hunk matches that.