故障处理
Codex 改了代码却找不到？定位 worktree、核对 diff 与带回本地
Codex 显示修改完成，本地文件却没变化、git status 仍干净？定位实际 worktree，区分未提交、已提交与未跟踪改动，再安全带回目标目录并验证。
Codex 说已经改完文件，你在平时打开的仓库里却看不到变化，git status 也是干净的。先确认任务实际在哪个 checkout 执行：独立 worktree 有自己的文件与暂存区，修改不会自动出现在你当前打开的目录中。
本文处理 codex worktree changes、Codex 改动找不到，以及主目录看不到 diff 的情况，重点是桌面应用的 Worktree 任务；其中 Git 检查命令也适用于手动创建的工作树。若只是找不到聊天记录，先看 恢复上次会话。
先按现象选下一步
| 现象 | 下一步 | 应该确认什么 |
|---|---|---|
| 主目录没有变化，任务在 Worktree 运行 | 找到任务对应的实际路径 | 两边是否属于同一仓库的不同工作树 |
找到了 worktree，git diff 仍为空 |
同时查暂存区、未跟踪文件与提交 | 改动处于哪种状态，而非直接判定丢失 |
| 分支名为空或显示 detached HEAD | 核对提交与文件，再保存到新分支 | 没有关联分支不代表没有文件或提交 |
| 文件已经存在，IDE 或浏览器显示旧内容 | 检查编辑器目录和开发服务目录 | 查看与运行的是不是刚才那份 checkout |
| 列表中的目录不存在 | 核对主机、挂载与托管恢复入口 | 是环境不可达、工作树已归档，还是目录被删除 |
先保留任务中的路径、分支或提交信息。在确定改动去向前，不运行 reset --hard、clean -fd，也不删除或 prune 工作树记录。
1. 从任务入口核对实际目录
适用情况： 桌面任务显示 Worktree，或者你不知道 Codex 改的是哪份文件。
打开对应任务，查看当前环境和目录；通过任务顶部的 Open 入口在编辑器中打开该工作树，或使用该任务的集成终端。在这个终端运行：
git rev-parse --show-toplevel
git status --short --untracked-files=all第一条显示当前 Git 工作树的根目录。把它与原来 IDE 打开的目录比较；macOS/Linux 还可用 pwd，PowerShell 用 Get-Location 核对终端所在位置。
预期结果： 能得到任务实际使用的绝对路径。如果提示不是 Git 仓库，先回到任务关联的项目目录；不要对着另一个同名目录继续执行带回操作。
官方默认把托管 worktree 放在 $CODEX_HOME/worktrees，桌面设置中的 Settings → Worktrees → Worktree root 可以改变位置。它也可能在连接的另一台电脑或远程开发环境中。不要只搜索本机默认目录，就认定工作树不存在。
2. 用 git worktree list 找同一仓库的其他 checkout
适用情况： 任务路径不明确，但你能进入原仓库。
在该仓库的终端运行：
git worktree list --porcelain按每组 worktree 路径、HEAD 提交，以及 branch 或 detached 信息定位候选目录。列表只属于当前这个 Git 仓库；另一次独立 clone 的工作树不会出现在这里。
验证： 用任务给出的路径、提交和文件名交叉核对，再在候选目录运行下一节的命令。不能只凭目录里出现一个相同文件名，就认定找到了本次修改。
如果列表没有目标，先核对是否进入了另一个 clone、另一台主机或容器。若标有 prunable 或路径暂时不可达，先检查挂载及归档状态；清理记录不会替你恢复文件。
3. git diff 为空？分别查三种未提交状态
把下面的 WORKTREE_PATH 替换为刚确认的实际绝对路径，保留引号；这些检查不切换分支，也不修改文件内容。
git -C "WORKTREE_PATH" status --short --untracked-files=all
git -C "WORKTREE_PATH" diff
git -C "WORKTREE_PATH" diff --cached
git -C "WORKTREE_PATH" ls-files --others --exclude-standard| 检查结果 | 含义 | 下一步 |
|---|---|---|
diff 有内容 |
已跟踪文件有未暂存修改 | 核对是否是本次任务的预期差异 |
只有 diff --cached 有内容 |
修改已进入暂存区 | 继续审查暂存内容，不要重复覆盖文件 |
status 有 ??，最后一条列出新文件 |
文件尚未被 Git 跟踪 | 打开并审查这些文件；普通 diff 不包含它们 |
| 三类都为空 | 当前 checkout 没有这些未提交修改 | 继续检查是否已经提交，或是否找错目录 |
对已跟踪文件，git -C "WORKTREE_PATH" diff HEAD 可以合看相对当前提交的暂存与未暂存变化，仍不包含未跟踪文件。被忽略的文件也不会被上面的未跟踪列表列出；若任务明确提到某个本地配置文件，用编辑器核对该文件，并用 git -C "WORKTREE_PATH" check-ignore -v -- "实际文件路径" 查看忽略来源，不要为了让它出现就加入版本控制。
验证目标： 你应能列出实际文件及其状态。只看到 git diff 空白，还不足以判断 Codex 没有修改。
4. 已经提交，或处于 detached HEAD 时怎么确认？
在已确认的工作树检查最近提交：
git -C "WORKTREE_PATH" log -5 --oneline --decorate
git -C "WORKTREE_PATH" show --stat --oneline HEAD最近五条只是查找起点；任务较早时应扩大范围。把任务给出的提交与文件清单对应起来；需要看更早提交时，将下面的 COMMIT_SHA 替换为已核实的提交：
git -C "WORKTREE_PATH" show "COMMIT_SHA"预期结果： 如果修改已经提交，工作区干净、普通 diff 为空都可能正常；提交内容才是接下来带回的对象。detached HEAD 表示当前检出的是提交而非命名分支，也是官方托管工作树的默认起点，不应因此重置目录。
若仍没有对应文件或提交，回查任务中实际执行的编辑记录、目标主机和错误。模型说“完成了”不是文件写入证明；需要看到路径、文件内容或提交差异。
5. 确认改动后，选择一种带回方式
桌面应用：优先使用 Hand off 到 Local
适用情况： 这是应用关联的 Worktree 任务，希望在常用本地 checkout 继续工作。
先核对源工作树的改动和目标 Local 目录的现状，再从任务顶部选择 Hand off → Local，阅读具体迁移提示。官方说明该流程会处理任务与代码在两个 checkout 之间移动所需的 Git 操作。
验证： 完成后，从任务当前终端重新运行 git rev-parse --show-toplevel 和 git status，再打开本次目标文件，核对差异或提交。不要只凭环境标签变成 Local 就结束检查。
如果提示分支已在另一工作树使用，保留现状并核对关联路径。Git 通常不允许同一分支同时检出到两棵工作树；不要加 force 绕过。需要继续在原工作树开发时，也可以使用应用的 Create branch here 保存为分支，在那棵树上审查和提交。
手动 Git：审查后保存为分支，再带回一个明确提交
下面只适用于熟悉 Git、目标 checkout 干净，并且本次工作可以整理为一个独立普通提交的情况。多提交、合并提交或复杂依赖应先审查历史，不照搬单提交命令。
如果源工作树处于 detached HEAD，可先创建一个尚不存在的新分支。以下命令在源工作树执行；名字已存在时换一个新名字，不覆盖旧分支：
git switch -c codex/recovered-worktree已在合适分支上就不必再建分支。对于尚未提交的改动，先确认暂存区没有混入别人的工作，再只暂存自己审查过的文件。把两个示例路径替换为实际文件，包含需要带回的未跟踪新文件：
git add -- "src/example.ts" "docs/example.md"
git diff --cached
git commit -m "Preserve reviewed Codex changes"
git log -1 --oneline预期结果： 得到一个内容明确的提交。若修改原本已提交，直接确认那个提交及其依赖，不创建空提交。
在目标 checkout 先运行 git status --short --untracked-files=all。只有确认没有待处理改动、提交来自同一仓库且是本次需要的独立提交后，才执行：
git cherry-pick "COMMIT_SHA"将 COMMIT_SHA 替换为审查后的实际提交；已经包含该提交时不必重复带回。发生冲突就停下来审查；不准备处理时，可用 git cherry-pick --abort 取消本次正在进行的 cherry-pick，再重新选择带回方法，不强行覆盖文件。
6. 文件已带回，为什么运行结果还是旧的？
适用情况： 目标文件正确，但浏览器、测试或 IDE 仍显示旧结果。
检查编辑器打开目录与开发服务启动目录，确认它们都指向目标 checkout；另一个 worktree 里的旧服务可能仍占用原端口。只停止并重启你已确认属于这个项目的服务，再运行项目原有的相关测试或构建。
未被 Git 跟踪的本地依赖、忽略文件与环境配置要单独核对。官方 .worktreeinclude 用于新建本地托管工作树时复制选中的忽略文件，有适用范围和限制，不能当成迁移所有现有文件的开关；不要把密钥文件提交到 Git。
规则、配置或工具也因目录切换而表现不同时，可继续查 AGENTS.md 不生效、config.toml 不生效；外部工具连接异常看 MCP 连接失败与超时。
7. 工作树目录已经不存在怎么办？
先核对正确主机、工作树根目录设置和挂载状态。对于应用管理的工作树，官方说明在其自动清理前会保存快照，重新打开关联任务时可出现恢复入口；按实际界面恢复后，再从目录和差异检查开始。
这不代表任意手动删除的目录、未保存文件或第三方工作树都能恢复。没有托管恢复入口时，保留现有仓库与备份，结合已保存的提交查找，不把 prune、删除任务或重新 clone 当作找回未提交文件的方法。
完成前核对四件事
- 任务、编辑器与终端指向预期 checkout。
- 已跟踪、已暂存、未跟踪和已提交的内容都已按实际状态核对。
- 目标目录里的文件或提交与审查结果一致，没有覆盖其他工作。
- 相关测试或开发服务在目标目录通过；需要复核差异时参考 Codex 代码审查流程。
仍失败时，准备客户端版本、执行主机类型、脱敏路径、worktree list 与 status 的必要片段、对应提交和本次迁移错误。目录可能包含用户名与项目名，分享前先脱敏。