沙箱平台支持与诊断

CLI 能在某个平台启动，不表示该平台一定能执行本地沙箱。沙箱使用 Microsoft eXecution Container（MXC）对接不同系统后端，支持范围与命令行工具本身不同。

平台前提

平台	后端	核对事项
macOS	Seatbelt	官方建议 macOS 15 Sequoia+；旧版不被 CLI 明确阻止，但未测试
Linux	bubblewrap	bwrap 在 PATH，版本至少 0.5.0
Windows	ProcessContainer 的 BaseContainer	必须由系统提供 BaseContainer，不使用 AppContainer 后备层

Windows 使用教程仍标注 Windows Insiders build；应用配置专题则列 Windows 11 25H2 + KB5124010 或 26H1 + KB5124006 及以上更新，均要求 BaseContainer。概览指向支持版本列表，不能将不同说明推断为所有客户端同一最低版本。Windows 具体 build 以 Microsoft 官方支持列表与 /sandbox status 为准，不把所有 Windows 11 都列为已支持。

Linux 出站网络依赖

允许外网访问时，还需要 PATH 上的 slirp4netns，以及 util-linux 2.35+ 的 unshare、nsenter，支持 --map-current-user 和 --keep-caps。同时需要 iptables、ip6tables 及对应 restore 程序，并可访问 /dev/net/tun。

官方推荐 nf_tables 后端；legacy 后端只有能够写入 /run/xtables.lock 时才可用。配置上游代理时同样需要这些出站网络依赖，不是只安装 bubblewrap 就足够。

代理执行差异

平台	当前概览和配置参考的描述
macOS	注入 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY；忽略这些变量的程序可直接联网
Linux	私有 network namespace，只允许访问代理端点；代理需 IPv4 可达，URL 不能嵌入凭据
Windows	不支持沙箱代理；配置代理时命令失败

上表保留统一概览及 CLI 配置参考的描述，但其他官方章节尚未统一：旧 CLI 配置教程写 macOS/Linux 协作式、Windows 强制；应用路径下配置专题的 CLI 部分又写 macOS/Linux 强制走本地代理、Windows 依赖程序遵循代理且需要 Local network。不能据这些冲突宣称某个平台的所有版本都可强制代理，也不能无条件认定新版 Windows 完全不支持代理。

应用配置专题进一步区分：Linux 命令在私有网络空间可访问那里启动的服务，但不能直连宿主 localhost；允许 local 且无远程代理时，可经内置本地代理访问宿主 localhost。macOS 启用本地代理时，打开 local 可监听端口，但不意味着能直连自己监听的端口；Windows 代理沙箱里的服务也不保证宿主 localhost 可达。Git/gh 默认凭据遮蔽本身就可能启用本地代理，不能只检查是否手填了 proxy URL。

拒绝路径与不可执行策略

统一概览把 Windows CLI 的 deniedPaths 列为不支持，应用配置专题则按系统是否具备拒绝路径能力判断。无法落实指定策略时，两者都要求沙箱命令失败，而不是静默移除限制；以实际版本和有效策略为准。

这与“主机完全不支持沙箱”的处理不同：普通 CLI 会话可能为本会话关闭沙箱并提示，然后无隔离运行；企业强制策略则拒绝执行。两种情况都应查看 /sandbox status 和报错，不要只读取 settings.json 推测当前行为。

排查顺序

1. 确认已开启 experimental，并在当前会话启用沙箱。
2. 用 /sandbox status 查看实际状态。
3. Linux 核对依赖、版本和设备权限；Windows 核对 BaseContainer 支持。
4. 用 /sandbox policy 检查当前目录下的合并规则。
5. 若某条策略不被平台支持，调整工作环境或策略，不把失败视为权限已落实。

内置文件工具与子进程的强制层不同，进一步说明见文件系统策略。

桌面应用在首个沙箱 Shell 启动时核对支持情况，无法落实策略时拒绝执行，不使用普通 CLI 上述无隔离回退；设置显示 Sandbox unavailable 时，修复问题后 Retry sandbox。详见桌面沙箱。