Capture
One read of Claude Documentation
5 pages moved out of 218 read.
government/security/security-and-data-handling Changed · +9 / -1 lines
from line 38
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.
from line 61
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>
from line 151
<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?">
third-party/claude-desktop/code Changed · +2 / -2 lines
from line 49
} ``` -With `"merge"`, Claude Desktop's policy values are layered under your Claude Code policy. Your values win any conflict, deny and allow lists are unioned, and Claude Desktop's values are filtered so they can only tighten policy, never loosen it. See [`parentSettingsBehavior`](https://code.claude.com/docs/en/settings#available-settings) in the Claude Code settings reference. Requires Claude Code v2.1.133 or later, which ships with Claude Desktop on 3P. +With `"merge"`, Claude Desktop's policy values are layered under your Claude Code policy. Your values win any conflict, deny and allow lists are unioned, and Claude Desktop's values are filtered so they can only tighten policy, never loosen it. See [`parentSettingsBehavior`](https://code.claude.com/docs/en/settings-reference#parentsettingsbehavior) in the Claude Code settings reference. Requires Claude Code v2.1.133 or later, which ships with Claude Desktop on 3P. <Note> In a third-party deployment there is no Anthropic authentication, so Claude Code's server-managed settings tier is never present. If you have not separately deployed a Claude Code `managed-settings.json` or OS profile, Claude Desktop's policy applies automatically and you do not need to set `parentSettingsBehavior`.
from line 57
## Further reading -* [Claude Code settings reference](https://code.claude.com/docs/en/settings) +* [Claude Code settings reference](https://code.claude.com/docs/en/settings-reference) * [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing) * [Settings precedence](https://code.claude.com/docs/en/settings#settings-precedence)
government/connectors/microsoft-365 Changed · +1 / -1 lines
from line 105
| **Azure cloud** | **Commercial** for most tenants, including Microsoft 365 GCC. Choose **US Government GCC-High** or **US Government DoD** only if your Microsoft tenant is in one of those clouds. | | **Access** | The Microsoft Graph permissions the connector requests when a member signs in. The standard read-only permissions are already selected; add or remove permissions as needed. See [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow). | -Save the card. The connector is delivered to each member's Claude Desktop the next time it refreshes its configuration, which happens at launch or sign-in. Members who already have Claude Desktop open may need to restart it. +Save the card. The connector reaches each member's Claude Desktop the next time it starts or the member signs in to Claude for Government. Members who already have Claude Desktop open are prompted to relaunch the next time the app checks for changes, which it does about every 30 minutes, and the connector appears after the relaunch. ## Choose which Microsoft 365 permissions to allow
government/org-admin/overview Changed · +3 / -1 lines
from line 75
## How changes take effect -Most changes you make in this portal take effect immediately. Changing a user's seat tier, updating a spend limit, or resetting a user's rate limits applies to their very next request. Product configuration changes are picked up the next time a user's Claude application refreshes its settings, which happens when the application is launched or when the user signs in. Group mapping changes trigger an immediate re-sync so you do not need to wait for a scheduled cycle. +Most changes you make in this portal take effect immediately. Changing a user's seat tier, updating a spend limit, or resetting a user's rate limits applies to their very next request. Group mapping changes trigger an immediate re-sync so you do not need to wait for a scheduled cycle. + +Settings on the [Config](/docs/government/org-admin/configuration) page that govern the Claude applications themselves, such as the Claude Desktop banner and telemetry, reach each user's application the next time it starts or the user signs in. Claude Desktop also checks for changes about every 30 minutes while it is running and prompts the user to relaunch when something has changed.
government/config/settings Changed · +3 / -1 lines
from line 110
### Allowed network hosts -A list of hostnames that tools in Claude Desktop may reach, for example to install packages or fetch web pages. This covers the tools Claude uses during Cowork tasks, web fetch in Chat, and the sandboxed shell commands of Code sessions on macOS. For how the list applies to Code sessions on each operating system, see [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop). The connection to Claude is always allowed and does not need to be listed. An empty list shows as **Claude connection only**. Use **Add package registries** to add npm, PyPI, GitHub, crates.io, and other common registries so that Claude can install libraries; hosts added this way appear together as a single **Package registries** pill with a count. This list does not cover addresses on your private network, direct IP addresses, or Web search, so do not rely on it alone to restrict network access. +A list of hostnames that tools in Claude Desktop may reach, for example to install packages or fetch web pages. This covers the tools Claude uses during Cowork tasks, web fetch in Chat, and the sandboxed shell commands of Code sessions on macOS. For how the list applies to Code sessions on each operating system, see [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop). The connection to Claude is always allowed and does not need to be listed. An empty list shows as **Claude connection only**. Use **Add package registries** to add npm, PyPI, GitHub, crates.io, and other common registries so that Claude can install libraries; hosts added this way appear together as a single **Package registries** pill with a count. + +Entries are hostnames or wildcard patterns such as `*.example.com`, which matches subdomains at any depth but not `example.com` itself, so list both if you need both. The list does not accept IP addresses or ports, and unless you allow all traffic with a `*` entry, the tools this list covers cannot reach a destination by its IP address. Web search, connectors, and the app's own connections, such as sign-in, updates, and telemetry export, do not use this list. Web fetch refuses localhost and private-network addresses regardless of what the list contains. Because entries match by name, a hostname you list is reachable even when it resolves inside your network, so treat the list as one layer alongside your own network controls. ### Allowed workspace folders