Codex 审批等待漏提醒的配置排查

把长任务交给 Codex CLI，切去处理别的事，回来却发现它早就停在审批上。原文给出的解释是：通知默认开着，但能不能提醒到你，还取决于终端焦点、通知方式，以及当前等待的到底是哪类输入。

解决办法分三层：先让通知稳定出现，再按需减少审批打断，最后把业务问题接到可远程回复的渠道。对经常在 VS Code 里跑 Agent 的程序员，这比单纯寻找「后台执行」开关更有用。

为什么开着通知，还是会错过审批

Codex 的终端界面会区分几种事件：approval-requested 对应命令、编辑和 MCP 审批，agent-turn-complete 对应一轮任务结束，计划模式提示和提问也有各自的类型。

问题出在通知送达的条件上。tui.notification_condition 默认是 unfocused，终端窗口仍有焦点时不会触发。人可能已经拿起手机，窗口却仍处于聚焦状态。

另一层是通知方法。按作者查阅的源码，tui.notification_method 默认值 auto 只在 Ghostty、iTerm2、Kitty、Warp、WezTerm 中发送 OSC 9 桌面通知。Apple Terminal、VS Code terminal、Windows Terminal、GNOME Terminal、Konsole、Alacritty 收到的是普通响铃字符，能否听见取决于终端设置。

还有两个容易查错的方向：notify 只在 agent-turn-complete 时运行程序，审批不会触发它；页脚出现 Waiting for startup 则表示 Codex 仍在启动，通常涉及 MCP 连接，并非等待审批。启动完成或服务器启动超时后才会发送输入，原文给出的默认超时是 10 秒，按 Esc 可以取消发送。

怎样让审批真正提醒到你

先调整 ~/.codex/config.toml，让通知不再受窗口焦点限制：

[tui]
notifications = true
notification_condition = "always"
notification_method = "bel"

关键是 notification_condition = "always"；bel 仍依赖终端响铃。终端支持 OSC 9 时，可以改成 "osc9"。只关心审批和任务结束，也可以把 notifications 设成 ["approval-requested", "agent-turn-complete"]。

Apple Terminal 需要在 Settings > Profiles > Advanced 开启 Audible bell。使用 tmux 时，还要在 ~/.tmux.conf 加入 set -g allow-passthrough on，再运行 tmux source-file ~/.tmux.conf，允许通知穿透。

如果希望直接调用系统通知，可以使用 PermissionRequest hook。它会在 Codex 准备请求审批时运行，适用于沙箱提权、网络请求，以及需要审批的 MCP 调用。下面是原文放进 ~/.codex/hooks.json 的 macOS 配置：

{
  "hooks": {
    "PermissionRequest": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Codex is waiting for approval\" with title \"Codex\"'",
            "async": true
          }
        ]
      }
    ]
  }
}

这里要看 async: true：通知命令异步运行，避免拖延审批提示。没有 matcher，表示匹配所有审批请求。新增后需打开 /hooks，审阅并信任它；hook 没有输出审批决定，所以原来的审批仍要回答。

macOS 没有弹窗时，作者建议检查 System Settings > Notifications 中 Script Editor 的权限，osascript 通过它发送通知。Linux 对应命令是 notify-send 'Codex' 'Codex is waiting for approval'。

另一个配置位置陷阱是：项目内 .codex/config.toml 的 notify 会被忽略，并产生启动警告，应放到 ~/.codex/config.toml。

减少打断之前，先分清它在等什么

原文描述的默认 Auto 预设使用 workspace-write 沙箱和 on-request 审批，主要在工作区外编辑或访问网络时询问。可以用 /permissions 切换预设，用 /status 查看当前策略和可写目录。

进一步设置 approvals_reviewer = "auto_review"，会把符合条件的请求交给 reviewer agent。它会拒绝关键风险操作，/approve 可以重试最近的一次拒绝，但审查需要额外模型调用。MCP 还能通过服务器级 default_tools_approval_mode 或单工具 approval_mode 配置 auto、prompt、writes、approve；原文没有展开各值的完整边界。

去掉提示，不等于操作就能成功。

--ask-for-approval never 保留沙箱，受阻操作会失败；--dangerously-bypass-approvals-and-sandbox，别名 --yolo，则同时移除审批和沙箱。原文称 OpenAI 不推荐后者。

远程处理也要区分两条路径。按原文，ChatGPT mobile app 可以跟进经 ChatGPT desktop app 连接的电脑任务、审批命令和发送指令。连接入口是 Settings > Connections > Control this Mac or PC，可用性取决于 rollout 和工作区设置，电脑必须保持唤醒、联网。

Taskhold 处理的是业务决策。作者建议在 AGENTS.md 写明：需要决策时，调用 taskhold_block 提出一个具体问题，然后领取下一项 todo，并在步骤之间调用 taskhold_updates 检查回复。任务会进入看板的 Needs you 区域，打开的看板标签页可以显示桌面通知，人可以从手机浏览器回复。

但它不能代答沙箱审批，也不能唤醒已经停止的会话。Codex 要再次调用 taskhold_updates，才会读到回复。

我的判断

这篇最有价值的地方，是把通知链路拆清楚了。对于 VS Code 用户，先确认收到的是桌面通知还是响铃，比反复检查「通知是否开启」有效。

不过，文章提供的是配置说明和源码解读，没有给出不同终端的送达率、hook 成功率，或自动审查减少多少等待时间的对照数据。文末标注的资料核查日期是 2026-10-31，具体行为仍需结合所用版本判断。

Taskhold 部分也应按产品方案看待。它由 Great Work LLC 提供，每人 $12/month 或 $120/year，有需要银行卡的 7 天试用，没有免费计划。原文没有证明它比已有任务看板更适合一般团队。

它的关键前提是：任务能拆开，Agent 遇到问题后还有其他工作可做，并持续轮询。若一个决策卡住了后续全部步骤，「先做下一项」就不成立。只想解决审批提醒时，前两种配置已经更直接。

能拿来做什么

• 在 VS Code 或系统终端运行长任务前，先用一次确实需要审批的操作验证提醒，分别检查焦点条件、响铃设置和系统通知权限。
• Node 项目反复卡在网络访问或工作区外写入时，先用 /status 查看限制，再通过 /permissions 调整适合当前任务的预设。
• 需要自定义审批提醒时使用 PermissionRequest，把 notify 留给任务结束通知，避免把两类事件接错。
• 有多个独立任务时，再考虑用 taskhold_block 和 taskhold_updates 承接业务问题，并把持续检查回复的要求写进 AGENTS.md。