Codex 为什么会卡在审批和 Worktree？一篇讲透新版 Codex 的真实故障点

很多人最近开始用新版 Codex，第一反应往往不是「这玩意真能干活」，而是「它是不是又死机了」。原因也不复杂。OpenAI 在 2026 年 4 月 16 日把 Codex 明确推成了更广义的工作空间，加入了 in-app browser、computer use、thread automations 等能力，目标是让它处理更长、更杂、更接近真实工作的任务。问题是，能力一旦往执行层扩，故障也会从「回答不对」升级成「流程卡住」「终端假死」「Worktree 跑不起来」「权限弹窗把人吓一跳」这种更工程化的麻烦。

先说最常见的误判

很多人看到 Codex 停在那里，就认定它卡死了。OpenAI 官方排障文档给的第一条建议却不是「重启」，而是先检查 Codex 是否在等待 approval。

这背后有个很容易被忽略的机制差别。OpenAI 在 sandbox 文档里明确说，sandbox 和 approval 是两套不同控制：

| 机制 | 作用 | 控制内容 | |------|------|----------| | Sandbox | 技术边界 | 定义 Codex 能访问什么资源 | | Approval Policy | 行为控制 | 决定 Codex 什么时候必须停下来问你 |

也就是说，很多你以为的「傻站着不动」，其实不是它坏了，而是它被设计成不能越权乱跑。

第一类故障的正确排法

如果线程看起来卡住，先别急着杀进程。官方建议的顺序是：

1. 先看是不是在等 approval
2. 再打开内置终端跑一个最基础的命令，比如 git status
3. 如果还不对，再新开一个更小、更聚焦的线程

这个顺序看起来有点保守，但非常实用，因为它先判断「是不是假卡」，再判断「是不是上下文太重」，最后才考虑重启。很多人上来就把整个 app 关了，结果不是解决问题，而是把线索也一并清空了。

第二类高频问题：终端看着像死了

Codex 官方的处理方法也很朴素：

1. 关掉终端面板，再用 Cmd+J 重新打开
2. 然后重跑 pwd 或 git status
3. 如果命令表现怪异，先确认当前目录和分支
4. 如果还是卡，等活跃线程结束后重启 app

这里有个很关键的现实点：OpenAI 在功能文档里明确写了，每个线程都带一个内置终端，而且这个终端是绑定当前项目或 worktree 的。

也就是说，你看到的「终端异常」，不一定是终端本身坏了，也可能是：

• 你已经跑到了另一个目录
• 另一个 worktree
• 当前线程状态和你脑子里的状态根本不是一回事

第三类问题：Worktree 里的代码为什么跑不起来

这也是新版 Codex 最容易让人骂娘的一类问题。

OpenAI 官方把原因说得很明白：

worktree 是在另一个目录里创建的，而且只继承已经提交到 Git 的文件。

也就是说，凡是你本地还没 commit 的依赖、脚本、工具配置、手工准备过的环境，worktree 默认都不会替你继承。

官方建议

| 场景 | 解决方案 | |------|----------| | 项目依赖额外 setup | 用 local environment 在 worktree 里再跑一遍 | | 不想折腾 worktree | 干脆切回 regular local project |

说白了，worktree 不是你的主工程目录克隆体，它是一个隔离分支工作区。你把它当「原地复制粘贴」，它当然会给你脸色看。

Codex 的三种工作模式

官方功能页写得很清楚，新线程可以选三种模式：

| 模式 | 说明 | 适用场景 | |------|------|----------| | Local | 直接在当前项目目录干活 | 日常开发、快速迭代 | | Worktree | 用 Git worktree 隔离改动 | 并行试验、多线程任务 | | Cloud | 跑远程环境 | 需要云端资源、团队协作 |

Worktree 的价值，本来就是把改动和你手头未完成的本地工作隔开，适合并行试验和多线程任务；代价则是它天然更依赖 Git 状态、更依赖已提交内容，也更容易暴露环境准备不完整的问题。

很多人把 Worktree 当成「更安全的 Local」，其实它更像「隔离更强、但更讲规矩的 Local」。

第四类问题：Codex 乱改文件？可能是你误会了

这个问题非常阴险，因为它会让人误会 Codex 乱改文件。

现象：侧边栏或 review pane 里出现 Codex 没改过的文件

真相：不一定是 Codex 动了它们，而是因为项目在 Git 仓库里时，review panel 默认显示的是整个 Git state。

官方解法

如果你只想看 Codex 最近一轮真正改了什么，把 diff pane 切到 「Last turn changes」。

这条非常关键，因为很多人本地仓库本来就有未提交改动，一进 Codex 看见一大片 diff，就开始怀疑人生。结果冤枉半天，最后发现是自己原本的脏工作区。工具背锅这件事，在 Git 世界里尤其常见。

第五类问题：本地环境配置明明共享了，Codex 却像没看见

OpenAI 的官方解释是：本地环境配置必须放在项目根目录下的 .codex 文件夹里。

如果你在 monorepo 里工作，还必须打开那个真正包含 .codex 的目录。

这个坑很典型，因为 monorepo 用户最容易以为「我都在这个仓库里了，Codex 应该自己懂」。现实很无情，路径不对就是不对。你打开了一个更上层或更偏的目录，Codex 就不会自动帮你脑补「真正项目根在哪」。

第六类问题：macOS 权限弹窗莫名其妙冒出来

甚至看起来像要访问 Apple Music。

这个现象 OpenAI 官方也单独写了。原因不是 Codex 突然迷上了音乐，而是它在执行任务时可能需要浏览文件系统；而 macOS 对 Music、Downloads、Desktop 这些目录本来就要求额外用户批准。

如果 Codex 需要读你的 home 目录，系统就会弹出访问这些文件夹的批准提示。

也就是说，这不是「Codex 行为异常」，而是 macOS 的安全模型在插手。你要真把这类系统权限提示误判成「中毒」或「产品发疯」，那排障方向就从一开始歪了。

第七类问题：自动化跑久了，worktree 越积越多

这个在新版 Codex 里很现实，因为官方已经把 thread automations 和 background workflows 做成了正式能力。

自动化页面明确写到：

在 Git 仓库里，automation 可以跑在 local project，也可以跑在 dedicated background worktree。

而排障页则提醒：频繁自动化会随着时间创建很多 worktrees，建议归档不再需要的 runs，别乱 pin。

这个问题不难修，但非常容易被忽略，等你发现磁盘和侧边栏都开始臃肿时，通常已经堆了一地工作树残骸。

第八类问题：看起来像「功能玄学」，其实是 CLI 和 app 版本不一致

OpenAI 官方说得很直接：

Codex app 和 Codex CLI 用的是同一个底层 agent 和配置，但它们在任意时刻依赖的 agent 版本可能不同，有些实验性功能也可能先落到 CLI。

版本检查命令

| 来源 | 命令 | |------|------| | 系统 CLI | codex --version | | App 自带 | /Applications/Codex.app/Contents/Resources/codex --version |

如果你碰到「CLI 能用、app 不能用」这种诡异情况，先别神化 bug，先把版本号对齐。

很多「为什么这边有那边没有」的问题，最后都死在这四个字上：版本不同。

真正实用的排障顺序

其实可以压缩成一句话：

先查 approval，再查 terminal，再查 worktree，再查 Git 视图，再查路径和版本。

因为新版 Codex 的很多问题，并不是某一个单点功能坏了，而是「线程模式、sandbox、approval、Git 状态、路径权限、app/CLI 版本」几层东西叠在一起造成的错觉。

你要是上来就一句「Codex 卡了」，那和跟医生说「我不舒服」差不多，信息量基本等于没有。

结语

新版 Codex 之所以更容易「看起来出问题」，不是因为它退步了，而是因为它开始真的去碰更复杂的执行链了。

OpenAI 自己在 4 月更新里就把方向写明了：Codex 正在变成一个更广义的 AI 工作空间，支持 in-app browser、computer use、longer-running tasks 和后续自动化。

能力越往前走，故障就越不像传统聊天工具那样简单粗暴。对技术人来说，这反而是好事，因为这说明它开始进入真实工程世界了。

只是进入真实世界以后，工具不会只给你惊喜，也会顺手给你一堆日志和审批弹窗。

世界就是这么体贴。