Security and data handling

 
 On macOS, 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. 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.
 
-The macOS 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. 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. See [Sandbox settings](https://code.claude.com/docs/en/settings#sandbox-settings) in the Claude Code documentation.
+The macOS 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. 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. See [Sandbox settings](https://code.claude.com/docs/en/settings-reference#sandbox-settings) in the Claude Code documentation.
 
 Exempting git commands such as `git commit` with `sandbox.excludedCommands` is not a safe way around the socket restriction. A sandboxed command can still change files that git runs during a commit, such as hook scripts kept in the working tree, and an exempted `git commit` would then run that code outside the sandbox. Git also cannot reach remotes over SSH from inside the sandbox, so a user who needs to push can use an HTTPS remote whose host is on the **Allowed network hosts** list, or push from a terminal outside the Code session.
 

     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). Anthropic-bound telemetry endpoints are not contacted in Claude for Government. Allow `downloads.claude.ai` for the sandbox virtual machine image and the Claude Code command-line tool, which are fetched at session start (not required if your agency uses the offline installer variant that bundles both), and `www.claudeusercontent.com` for the artifact preview frame. For automatic application updates, the required hosts depend on how your agency distributes the client; see the network-requirements table in [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) and confirm the update hosts for your deployment before finalizing your allowlist.
   </Accordion>
 
+  <Accordion title="Can administrators control when Claude Desktop updates?">
+    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.
+  </Accordion>
+
   <Accordion title="Does Claude for Government depend on claude.ai or anthropic.com?">
     The core product does 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 Cowork and Code sessions from starting and Advanced file analysis in Chat from running, unless the offline installer variant was used.
   </Accordion>

 
   <Accordion title="Where on the device is conversation content stored?">
     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.
+  </Accordion>
+
+  <Accordion title="Is local history kept separate for each organization?">
+    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).
   </Accordion>
 
   <Accordion title="Where are files added to a project stored, and are they indexed?">