One read of Claude Documentation

 
 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.
+
+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.
+
 On Windows, there is no operating-system-level sandbox for Code sessions. Shell commands run directly on the device under the permission mode the user selects for the session and under your agency's own endpoint and network controls. The **Allowed network hosts** and **Allowed workspace folders** settings do not confine what those commands can reach or change.
 
 On both operating systems, the application starts a Code session only in a folder that **Allowed workspace folders** permits when that setting is configured. Administrators can also require a prompt on every shell command, in every permission mode, with the **Require approval for each command** sub-setting on the **Shell commands** card of the [Config](/docs/government/config/settings#tool-and-connector-cards) page.

 
 Controls which folders members can pick as a project folder in Claude Desktop, and where Claude can read and write files. Leave it unset to allow any folder. Add folder paths to limit members to those locations, or check **Block all workspace folders** to allow none, in which case Claude can still work in Chat and Cowork in folders it creates inside its own sandbox. A Code session starts only in a folder this setting permits, and [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop) describes how the setting applies to Code sessions on each operating system. You can list Windows and Mac paths together, and each device uses only the paths for its platform. An unset value shows as **Any folder** and an empty list shows as **No folders**.
 
+Write each entry as an absolute path. A path can start with `~`, which stands for each member's home folder on both Windows and Mac; write these with forward slashes, for example `~/ClaudeWork`, and they resolve on both platforms. A path can also use one of the per-user variables `%OneDrive%`, `%OneDriveCommercial%`, `%OneDriveConsumer%`, `%APPDATA%`, `%LOCALAPPDATA%`, and `%USERNAME%`. A device ignores an entry whose variable it does not define, so a list with only Windows entries leaves Mac users with no allowed folder. Include a `~` path or a Mac path as well. Subfolders of a listed folder are included, Claude Desktop creates a listed folder that does not exist yet when a member opens the folder picker, and the picker opens in one of the listed folders.
+
+If your agency redirects Desktop and Documents to OneDrive or another sync client, consider listing a local folder that is not synced, such as `~/ClaudeWork`, for Code sessions and other work that creates many files or scripts. Keep synced folders for documents and finished work. To point at the synced Documents folder on Windows, use `%OneDriveCommercial%` or `%OneDrive%`, for example `%OneDriveCommercial%\Documents\ClaudeOutput`, because `~/Documents` refers to the local Documents folder in the user profile, not the redirected one. What the sync client uploads, including whether it skips particular file types, is controlled by your sync client's policies rather than by Claude for Government.
+
 ## Tool and connector cards
 
 Alongside the settings list, the Config page shows cards for the built-in tools (Web search, Web fetch, and Shell commands), the built-in connector (Microsoft 365), a **Connectors** card for the ones you add yourself, and a **Plugins** card for plugin packages you upload. A connector is an integration that lets Claude reach an external service on a user's behalf.