Codex 会话起错了执行目标：Local、Worktree、Cloud 三条路怎么认、怎么救

2026-08-09

有一类问题特别容易浪费半小时：你让 Codex（OpenAI Codex）改点东西，它也确实”改完了”，可你回到编辑器里一看，文件纹丝没动；或者反过来，本地仓库莫名其妙多出一堆你没建过的目录。这些多半不是模型出错，而是会话一开始就起在了你以为之外的执行目标上。

Codex 的执行目标大体分三类：跑在你当前工作树上的本地会话、跑在一个独立 Git worktree 目录里的会话、跑在 OpenAI 托管环境里的 Codex cloud 任务。它们产出的东西落在完全不同的地方，而”落在哪”这件事在会话开始那一刻就定了。

下面按排查该有的顺序走一遍。

一、现象：这几种表现都指向同一个根因

会话说改了某个文件，但本地 git status 干干净净，编辑器里也没变。
本地仓库里冒出你没建过的目录，里面像是同一个仓库的另一份。
你在这台机器上起的会话，在手机或网页上也能看到；或者相反，你换台设备想接着看，怎么也找不到。
会话里跑构建、跑测试直接失败，报的是缺依赖——可你本地明明装过。
你用 -m 指定了模型，实际用的却不是那个。

这几条对应的其实是不同的执行目标，而不是不同的 bug。

二、先确认：这一轮到底跑在哪

2.1 最省事的一刀：看这个会话在别的设备上有没有

官方对本地和云端的界线写得很直白：本地工作流在你自己的设备上运行，云端任务在 OpenAI 托管的环境里运行；云端 Work 会话会跨 web、移动端、桌面端同步，本地 Work 会话只留在你这台电脑上。

所以判定方法很粗暴但很有效：换个设备（或换个面）看这个会话在不在。在，它是云端的；不在，它就在本机。这一步不需要任何命令，先做它能省掉后面一大半排查。

2.2 CLI 侧：把”工作根目录”问清楚

如果你是从 Codex CLI 起的会话，最直接的判定是看 agent 的工作根目录到底指到哪。CLI 里控制这件事的是两个顶层选项（本机在 codex-cli 0.147.0（Windows 11）上从 codex --help 读到的原文）：

-C, --cd <DIR>：指定 agent 的工作根目录
--add-dir <DIR>：主工作区之外额外可写的目录

也就是说，只要你（或者某个脚本、某个 shell 别名）带了 -C，会话的根就不是你 shell 所在的那个目录。先把这两个选项从你的启动命令里找出来，比猜快得多。

配合 git 自带的命令做交叉验证（这两条是 git 的能力，不是 Codex 的）：

git rev-parse --show-toplevel
git worktree list

第一条告诉你当前所在的是哪个仓库根，第二条把这个仓库关联的所有 worktree 列出来。如果第二条列出了不止一行，而你改动”消失”的那个文件正好在另一行对应的目录里，答案已经出来了。

2.3 worktree：它本来就是另一个目录

官方排查页对 worktree 的定性很关键：worktree 是另一个目录，它继承了 Git 里的文件。这句话把两件事同时解释了——为什么你本地看不到改动（改动在别的目录），以及为什么那边跑不起来（被 Git 忽略的文件、本地装的依赖，都不会跟着过去）。

所以看到”缺依赖”别急着怀疑环境坏了，先确认这一轮是不是在 worktree 里跑的。

2.4 云端：用 CLI 自己查

Codex CLI 有一组查云端任务的子命令。本机在 codex-cli 0.147.0（Windows 11）上执行 codex cloud --help，它在帮助里被标注为 [EXPERIMENTAL]，说明是”浏览 Codex Cloud 的任务并把改动应用到本地”。子命令包括：

子命令	作用
`exec`	不启动 TUI，直接提交云端任务
`status`	（帮助文本未记录，按子命令名理解）
`list`	（帮助文本未记录，按子命令名理解）
`diff`	显示统一 diff
`apply`	把某个云端任务的 diff 应用到本地

判定就用 codex cloud list 和 codex cloud status：能在里面找到你那一轮，它就是云端跑的。要提醒一句，这组命令带 EXPERIMENTAL 标签，选项和行为可能随版本变，别把它写死进团队的固定流程里。

另外还有个侧面依据：官方说 Codex cloud 自动选择模型，而且 gpt-5.6-terra 与 gpt-5.6-luna 在云端不可用。所以”我明明指定了模型，跑出来不是那个”——这本身就是一条会话跑在云端的线索，而不是模型配置失效。

三、处置

按三种情况分开说。凡是涉及桌面应用和云端的部分，我们没有实测，只能给官方文档口径。

3.1 已经起错了、还在跑：先取消，别等它跑完

官方排查页对”会话起错了执行目标（Local / Worktree / Cloud）“这一条给出的做法是：取消这次运行，然后在 composer 里按上方向键找回原来的提示词，再用正确的目标重发一次。

这条是桌面应用侧的口径，我们没有亲测。它的价值在于告诉你不用手动重打提示词——起错目标最烦的就是那一大段精心写的指令，取消后不用重写。

3.2 起在 worktree 上，代码跑不起来

官方给的做法是两条：通过本地环境运行初始化脚本，或者用 .worktreeinclude 把被忽略的文件纳入进来。

第二条是这类问题的正解——那些被 .gitignore 挡住、但跑起来又必需的文件（本地配置之类），本来就不会跟着 worktree 走，.worktreeinclude 就是用来点名把它们带过去的。

3.3 起在云端，结果要拿回本地

CLI 侧有两条路：codex cloud apply（把某个云端任务的 diff 应用到本地），以及顶层的 codex apply <TASK_ID>——帮助里写的是”把 agent 产生的最新 diff 以 git apply 的方式打到你的本地工作树”。

用 git apply 落地这件事本身要留个心眼：它是打补丁，本地工作树如果已经有冲突性的改动，打不上是正常的，先把本地整理干净再打。

3.4 本来想要云端，结果起在了本地

官方对云端的定位是在隔离的云端环境里跑任务、可以并行、不占用本地机器，任务发起入口是 web、GitHub、Linear、Slack。上手是三步：用 ChatGPT 账号登录 Codex、连接 GitHub 账号并选择可访问的仓库、打开环境设置为仓库创建一个环境。

这三步有个很实用的推论：如果你从来没给这个仓库建过云端环境，那这一轮不可能跑在云端，别再往那个方向查了。

3.5 计划任务刷出一屏 worktree

这条容易被误当成”目标又起错了”。官方排查页的说法是：归档不需要的计划运行；除非你要保留 worktree，否则不要 pin。也就是说，多出来的 worktree 是计划任务的正常产物，处理方式是清理，不是改执行目标。

四、处置完怎么验证

别只看会话里那句”已完成”，按下面几处逐个对：

仓库层面：再跑一次 git worktree list，确认你现在待的这个目录，就是你期望改动落地的那个。
改动层面：git status / git diff 看文件真的变了。这一步是本地事实，最硬。
云端层面：如果这一轮是云端跑的，用 codex cloud status 或 codex cloud list 确认任务状态，再用 codex cloud diff 看清楚差异，最后才 apply。
配置层面：如果你顺手改了配置想让下次起对目标，先跑一次 codex doctor --summary。本机在 codex-cli 0.147.0（Windows 11）上故意用 codex -c 'features=[unclosed' doctor --summary 传了一段语法不合法的 TOML，doctor 没有崩溃、照常跑完，但结果里明确打出了一行 ✗ config config could not be loaded。这说明配置坏掉时命令还能跑，但配置根本没加载——“我改了配置怎么没生效”，第一步就该看这一行。

五、什么情况说明不是这个原因

排查最怕认准一个方向撞到底。下面几种表现长得很像”执行目标起错了”，但根因是别的，官方排查页各有各的条目：

diff 面板里出现不是 Codex 改的文件。原因是项目在 Git 仓库里，面板展示的是全部 Git 状态变更。官方给的做法是把 diff 面板切到 “Last turn” 视图，只看本轮改动。这是桌面应用侧口径，非亲测。
同事那套本地环境配置识别不到。原因是配置不在 .codex 文件夹里。官方给的做法是确保 .codex 文件夹在项目根；monorepo 要打开正确的那个目录。注意这条和执行目标的区别：目录确实可能开错，但表现是”配置读不到”，不是”改动落错地方”。
某个功能 CLI 里有、桌面应用里没有。原因是两个面的 Codex 版本不同，官方给的做法是分别查版本：CLI 用 codex --version，macOS 上的桌面应用用 /Applications/Codex.app/Contents/Resources/codex --version。这里补一条本机观测：同一台机器上，我们采集开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后同一条命令得到 codex-cli 0.147.0，期间 which -a codex 始终只有一个可执行文件。所以排查任何版本相关的问题，都要以当次实时输出为准，别用记忆里的版本号。
终端卡住没反应。官方给的做法是关掉面板、用 **Ctrl+```** 重开，先跑 pwd` 这类基础命令探一下。这跟目标起错没关系，是面板本身的状态问题。
侧栏只显示了一部分聊天。官方给的做法是点 “Chats” 旁边的筛选图标选 “Chronological”，并去 Settings 里检查归档。会话”找不到”未必是跑到别的地方去了，可能只是被筛掉或归档了。

最后说个习惯问题。这类坑之所以反复踩，是因为”这一轮跑在哪”平时根本不显眼，只有出事时才想起来问。相对省事的做法是把判定动作前置：起会话前先确认当前目录、确认启动命令里有没有 -C，云端任务提交后随手记一下任务标识——比事后满仓库找改动便宜得多。

顺带一句，learn.chatgpt.com 的任何文档页 URL 后面加 .md 后缀就能拿到 Markdown 版本，站点还提供 llms.txt（完整页面索引）和 llms-full.txt（合并全文）。排查时想快速核对官方原文，直接取 Markdown 版比在页面上翻要快。