Codex + 第三方模型：沙箱静默拒绝网络与工作区外写入，用户无提示、无出路

[zqchris]

问题描述 / What happened

Codex + 第三方模型（网关 / BYOK）在 Auto 档下，网络请求与工作区外写入被沙箱静默拒绝，用户看不到原因、也不知道能怎么办。

这不是审核器的问题——审核器根本没机会介入。链路是串联的两层，沙箱在前：

模型要跑命令
      ↓
  Codex 进程内的沙箱先执行
      ├─ 沙箱允许 → 直接跑完                    Cindy 不知道
      ├─ 沙箱拒绝 + 模型主动申请升级 → 审批请求 → Cindy 审核器 ✔
      └─ 沙箱拒绝 + 模型没申请 → 命令报错        Cindy 也不知道

第三条分支就是这个 issue：curl 报 exit=6（DNS 解析被拒）、写 ~ 报
operation not permitted，没有任何提示说明这是沙箱拦的、也没提示切到完全访问可以执行。
Agent 自己也不知道，可能反复重试。

为什么说是我们配置得过严

sandboxModeToPolicy（packages/maker-core/src/agents/codex/index.ts:622-634）在 workspace-write
下只传了 writableRoots：

case 'workspace-write':
  return {
    type: 'workspaceWrite',
    ...(extraWritableRoots.length > 0 ? { writableRoots: extraWritableRoots } : {}),
  };

而协议里 workspaceWrite 有四个可调项（codex/app-server/protocol.ts:444-450）：

字段	我们传了吗	后果
writableRoots	✅ 传了（塞了 codex memories 目录）	—
networkAccess	❌ 从未设置，走 server 默认（关）	网络全断
excludeTmpdirEnvVar	❌ 未设	默认允许写 /tmp（实测通过）
excludeSlashTmp	❌ 未设	同上

对照原生 codex：社区把 DeepSeek 等第三方模型接入 codex 时，普遍在
~/.codex/config.toml 里配 sandbox_mode = "danger-full-access" + approval_policy = "never"，
网络与工作区外写入都是通的。我们给出的环境比原生默认更压制，而且没有暴露任何放宽入口。

建议的三档（倾向 A）

档	改动	结果	审核器
A	networkAccess: true	网络通，写仍限工作区	保留
B	A + writableRoots 纳入用户配置的额外目录	网络通、指定目录可写	保留
C	换 danger-full-access	全通（等同原生常见配置）	失效

倾向 A 的理由：网络请求本来就在 reviewAction 的判据范围内（shared/auto-review.ts
有 network 分支与内网地址判据）。沙箱把网络整个掐掉，等于让审核器没机会审；打开之后，
判断权回到审核器——能放行就放行，红线才拦。这与「减少无意义阻断」的产品方向一致。

C 能解决所有阻断，但审核器一起失效，需要产品决策。

环境 / Environment

• Cindy v0.1.44（macOS）
• codex-cli 0.147.0-alpha.6.5
• 会话：Codex + moonshot/kimi-k3 + Auto 档 + xd 网关路由
• 对照：本机 ~/.codex/config.toml 为 danger-full-access / approval_policy = "never"

复现步骤 / Steps to reproduce

1. 新建 Codex 会话，模型选任一第三方 / 网关模型（如 Kimi K3、DeepSeek）
2. 权限档选「自动审批」
3. 让 agent 执行 curl https://registry.npmjs.org/react
   → 报 exit=6，无任何提示
4. 让 agent 执行 echo x > ~/probe.txt
   → 报 operation not permitted，无任何提示
5. 查 main-*.log：auto permission reviewer 零条调用记录，审批请求一条未产生

日志与截图 / Logs & screenshots

实测会话 d52af8e9-8c4c-4c87-8a6c-1c7050d09695（16 条命令）：

命令	结果
whoami / pwd / uname / sw_vers	通过
echo > 工作区文件	通过（工作区内写入正常）
echo > /tmp/...	通过
git status（只读）	通过
curl https://...	拦截 exit=6
ping 8.8.8.8	拦截 Operation not permitted
echo > ~/...	拦截 operation not permitted
ps aux / sudo -n ls	拦截

日志侧：grep -c "auto permission reviewer" main-2026-08-12.log = 0。

---

需要上游确认的两点

1. networkAccess: true 之后网络请求走哪条路

两种可能，未实证：

• 沙箱直接放行 → 审核器同样看不到（与读文件相同）→ 用户体验最好，零打扰
• 走审批流 → 审核器介入判断

两种都比现状好，但行为需要确认，以免误判「已生效」。

2. 两个未文档化的审批策略值

AskForApproval 的内部枚举有 5 个值，但 codex --help 的
--ask-for-approval 只文档化了 3 个：

值	CLI 文档	官方说明
untrusted	✅	只自动跑「可信」命令（ls/cat/sed），其余升级给用户
on-request	✅	模型自己决定何时问用户（我们现在用这个）
never	✅	永不询问用户；执行失败直接把错误返回给模型
on-failure	❌ 未文档化	仅存在于二进制枚举表
granular	❌ 未文档化	同上，配套 GranularApprovalConfig（sandbox_approval / rules / skill_approval / request_permissions / mcp_elicitations）

on-failure 从名字看正是我们需要的语义——命令失败后自动请求审批，不依赖模型
主动申请升级（第三方模型往往不会用 sandbox_permissions: require_escalated）。

但它未被文档化，可能是已废弃、未发布或仅内部可用。贸然切换的风险是 server 静默忽略
——我们以为策略生效、实际没有，用户照样被拒。 需要确认这两个值的真实状态与语义，
再决定是否可用。

风险边界（本 issue 不主张的事）

• 不主张收紧任何读权限。沙箱设计上允许读全盘（codex 自己的 Guardian 提示词原文：
  "The sandbox allows it read access everywhere"），这是 codex 的既定策略，且
  Guardian 明确写了 "Do not treat reads as high risk simply because they may contain
  some credentials"。本 issue 的方向是减少阻断，不是增加。
• 不主张改动 codex 已实现的沙箱机制本身。
• 审核器覆盖面窄（只看升级请求）在此仅作背景，用于解释沙箱拒绝为何我们管不到；
  它本身不是本 issue 要解决的问题。

相关

• PR fix(auto-review): 波动时重试并降级给用户确认，按模型能力给足额度 #2474（已合并）修的是另一半：审阅器故障时不再静默拒绝，改为重试 + 降级给用户确认，
  并按模型能力给足审核额度。那个 PR 解决「审核器自己拒绝用户」，本 issue 是「沙箱拒绝用户」。

[dash-s-cindy]

判断

这个问题值得处理：Codex Auto 在第三方/网关模型下存在一条用户无法有效接管的失败路径——命令先在 workspace-write 沙箱中失败，而模型没有产生升级请求时，Cindy 的审批与自动审阅链路不会被调用，用户只看到普通命令错误。当前 main@4318ebc87c6067a48df53aac826f677a8d0ae893 仍保留这一行为。

真正需要补齐的是：第三方模型未主动申请升级时的可靠兜底、沙箱失败归因和恢复入口。不建议直接把 Auto 改成默认 networkAccess: true，因为这会改变现有安全边界，并不能把网络动作交给 Cindy reviewer。

行动

1. 先针对当前捆绑的 Codex app-server 做端到端矩阵验证：
   • OpenAI OAuth 与第三方/网关路由；
   • curl/包管理器联网、工作区外单文件写入；
   • macOS，并至少补一个 Linux/Windows 沙箱实现；
   • 同时记录 item/started、item/commandExecution/requestApproval、Guardian/Cindy reviewer 调用以及结构化沙箱错误。
2. 将“命令失败且未产生审批请求”的沙箱拒绝变成可操作的终态结果：明确说明当前 Auto 的网络或写入边界，并提供与现有权限控件一致的恢复入口，例如经确认后重试，或提示用户切换 Full access。不要只把 exit=6、operation not permitted 原样留给 Agent 猜测。
3. 固化回归测试：第三方模型不发送升级参数时，网络和越界写入不得静默结束或无限重试；用户必须能看到原因和下一步。另测已有审批请求路径不被重复提示。
4. 对 on-failure 只做目标 Codex 版本的协议探针和真实执行验证。在确认 app-server 接受该值、失败后确实产生可消费的审批请求、且跨平台一致之前，不将其作为正式修复。

源码核对

当前权限映射

packages/maker-core/src/agents/codex/index.ts 中，Auto 当前映射为：

• 协议和原生 reviewer 路由可用：on-request + workspace-write + approvalsReviewer: auto_review；
• 第三方/网关等原生 reviewer 路由不可用：回退为 on-request + workspace-write + approvalsReviewer: user，由 Cindy 在审批回调上执行当前会话模型的审阅兜底；
• Full access：never + danger-full-access。

因此，第三方路由并非完全没有 Cindy reviewer；问题在于 reviewer 的入口仍然是 app-server 发出的审批请求。模型没有申请升级、app-server又只返回沙箱内执行错误时，这条 reviewer 链路不会启动。

网络默认值

同文件的 sandboxModeToPolicy() 在 workspace-write 下只设置 writableRoots，没有设置 networkAccess。协议类型 packages/maker-core/src/agents/codex/app-server/protocol.ts 明确表明：

{
  type: 'workspaceWrite';
  writableRoots?: string[];
  networkAccess?: boolean;
  excludeTmpdirEnvVar?: boolean;
  excludeSlashTmp?: boolean;
}

该协议文件也注明 workspaceWrite 的 networkAccess 默认是 false。所以报告中的断网原因与当前源码一致，最新主干没有已经落地的修复。

需要修正的方案判断

OpenAI 官方的 Agent approvals & security 说明：

• 默认 workspace-write 下网络关闭；
• 网络关闭时，联网属于需要越过沙箱边界的动作；
• 配置 sandbox_workspace_write.network_access = true 后，命令在沙箱内已经拥有网络；
• Auto-review 只评估那些仍然需要批准的动作，已在沙箱内允许的动作不会额外进入 reviewer。

因此，直接设置 networkAccess: true 的实际语义是“Auto 中的 spawned commands 默认可直接联网”，而不是“让网络请求回到 Cindy reviewer 判断”。共享 reviewAction() 虽然有 network 分支，但 Codex adapter 只有在收到相应审批/动作入口后才能调用它；沙箱已经允许的命令不会仅因该分支存在而被审阅。

这不代表永远不能开放网络，而是它应作为明确的产品权限选择或命名权限 profile 来决策和验证，不能作为本问题的无风险修复。

现有入口与边界

• 产品已经暴露 Full access，对应 danger-full-access，所以并非完全没有放宽入口；当前缺陷是沙箱失败没有告诉用户该入口与后果。
• Codex 已声明支持 Extra Dirs，但当前契约把附加目录作为只读引用目录；把它们加入 writableRoots 会扩大既有写权限，不应作为本缺陷的默认配套改动。若需要额外可写目录，应单独定义权限语义、授权 UX 和测试。
• 协议类型当前包含字符串值 on-failure，但公共官方文档列出的常用策略仍是 untrusted、on-request、never，并把 granular 表达为结构化策略而非同级字符串枚举。仅凭本地类型或二进制枚举不能证明 on-failure 在目标 app-server 上具有稳定、受支持的语义。

验收建议

至少覆盖以下结果：

场景	期望
Auto + 第三方模型 + 普通工作区内读写	无额外打扰，继续执行
Auto + 第三方模型 + 网络，模型主动申请升级	进入 Cindy reviewer/用户确认既有链路
Auto + 第三方模型 + 网络，模型未申请升级	不只显示 DNS 错误；明确归因于沙箱并给出可执行恢复入口
Auto + 第三方模型 + 工作区外写入，模型未申请升级	同上，不允许无提示反复重试
Auto + OAuth 原生 reviewer	保持 Guardian/原生 reviewer 优先，不重复审阅
Full access	行为不变，并继续明确展示其无沙箱边界的风险
reviewer 自身超时或故障	继续沿用 #2474 的重试与降级确认行为

还应验证恢复动作只重放目标命令一次，权限切换或拒绝后不会遗留挂起审批，也不会把一次确认错误持久化为更宽权限。

相关记录

• fix(auto-review): 保留宿主审批并用当前模型静默兜底 #1227：已合并并明确产品意图为“原生 reviewer 优先；第三方/网关路由保留宿主审批，并由当前会话模型做 Cindy 兜底”。本问题暴露的是该设计在“审批请求根本未产生”时无法接管。
• fix(auto-review): 波动时重试并降级给用户确认，按模型能力给足额度 #2474：已合并，将 reviewer 基础设施故障从静默拒绝改为重试后交给用户确认；它只覆盖 reviewer 已被调用的路径，未覆盖沙箱直接返回命令错误的路径。
• Auto-review 权限模式系统性 review:Codex 侧名不副实(实为 Full access)、默认档过激进、模式显示不稳定等问题与改进需求 #129：此前确立了 Auto 与 Full access 必须保持真实区分，并由 workspace-write + on-request 恢复 Auto 的沙箱边界。直接在 Auto 默认开放网络或把额外目录改为可写，属于对该边界的产品变更，需要单独确认，而不应随本缺陷默认落地。

[fico-hub]

关联进展:#3793 的「沙箱初始化失败(bwrap 起不来,命令从未执行)」半边已由 PR #3799 交付宿主归因——判定靠输出全部为 bwrap: 诊断行这一确定性形状。

本 issue 的「沙箱运行中逐命令拒绝(网络/工作区外写入)」半边经复核没有等价的确定性判定形状:被拒命令的 EPERM / curl exit=6 与真实命令错误在输出层不可区分,客户端侧无法安全归因;可靠修复杠杆只剩两条——①按三角建议补 workspaceWrite 协议旋钮与「模型未申请升级时的兜底升级请求」(改变 Auto 档安全语义,需产品拍板);②codex 上游在 item 上带结构化 sandbox-denial 标记后客户端才能做 #3799 式归因(上游依赖)。两条都超出无授权可改范围,故不认领修复,留此定界供后续拍板参考。