桌面应用的本地沙箱

本地沙箱限制本机代理工具可以访问的文件、网络和凭据。桌面应用与 CLI 分别保存沙箱设置，修改一端不会自动修改另一端。项目 worktree 只分开工作文件；它不限制命令访问机器上其他位置。

开启与生效范围

在 Settings → Projects → 项目 → Sandbox 打开 Sandbox new sessions。本地沙箱默认关闭，企业托管设置要求启用时除外。此设置用于该项目后续的本地仓库与 worktree 会话，不修改正在运行的会话；remote-only 项目没有该设置。

活动本地会话中可用 /sandbox on 或 /sandbox off 调整本次会话。没有活动会话时，这两个命令修改所选项目对新会话的默认值。cloud sandbox 和远程主机会话不支持本地沙箱。

文件、网络和凭据策略修改后，在新会话或现有会话重启时生效。用 /restart-session 可保留历史并重启。Configured policy summary 只说明请求的配置，不证明沙箱正在运行；企业策略可能进一步收紧它。

文件与凭据

默认允许读写工作区与当前工作目录。可通过 Additional read/write、Additional read-only、Denied 添加额外目录规则；更具体的拒绝目录不会因父目录可读写而自动解禁。

Git credentials 默认允许认证的 HTTPS Git；GitHub CLI credentials 默认允许 gh 认证，这里不是 copilot 的登录开关。禁用这些凭据可能阻止推分支或创建 PR。

应用也可请求单次绕过沙箱的批准，但项目界面不提供是否允许 bypass 请求的配置项；还需遵守企业策略。

网络默认值与平台差别

桌面应用的 Outbound internet 和 Local network 都默认开启。前者控制互联网服务连接，后者涉及 loopback 与局域网服务。

应用路径下的配置专题指出，Linux 沙箱进程不能直接连接宿主 localhost；本地网络设置仍控制通过内置本地代理的请求及进程内 Web/MCP 请求。其他平台也可能因代理和凭据遮蔽改变 loopback 行为，不能只看到开关打开就认定所有本机服务都可直连。

同一专题的 CLI 部分写明 Allow local network 默认关闭，旧 CLI 配置和使用专题则写默认开启。这个冲突不能通过把应用默认值套给 CLI 来解决；CLI 用户应检查实际 /sandbox policy 与当前版本设置。

系统依赖与失败处理

应用配置专题列出以下 Windows 前提：Windows 11 25H2 + KB5124010 或更高更新，或 26H1 + KB5124006 或更高更新，并支持 ProcessContainer 的 BaseContainer。Linux 至少需要 PATH 上的 bubblewrap 0.5.0+ 与 slirp4netns；统一概念页还列出出站连接的 util-linux、iptables 与 TUN 依赖，见平台诊断。

应用允许先保存配置，在第一个沙箱 Shell 启动时验证系统支持。若无法执行所请求的策略，命令以 unsupported-platform 或 unsupported-policy 失败，不会悄悄无沙箱运行。显示 Sandbox unavailable 时，解决提示的问题后点 Retry sandbox。

官方平台描述尚未统一

能力	应用配置专题	统一概念页中的 CLI 说明
macOS 代理与 host rules	强制经本地代理，不能直接绕过	依赖程序遵循代理环境变量
Windows 代理	支持的版本需打开本地网络，但忽略代理的程序可能绕过	不支持，配置后命令失败
Windows 拒绝路径	能力不足时拒绝执行，按版本检查	CLI 不支持；应用按实际能力检查

旧 CLI 配置专题又把 Windows 描述为强制代理，与上表两种说法不同。这里保留来源差异，不宣称跨版本统一保证。当前应用明确的失败处理与 CLI 普通会话在不支持主机上可能关闭沙箱的回退也不同，应分别核对。