Codex 断流前改过哪些文件：用 Git 还原一次任务的修改范围

Codex 中断后代码修改是否仍在，应以磁盘与 Git 差异为准。回复没结束、界面显示失败，都不能单独证明文件没动。先暂停继续编辑，记录中断时刻和仓库身份，再把“任务前已有”“任务后新增”“归属不明”三类变化列出来。以下是本地检查方法，不解释断流原因。

三份清单各解决一个问题

第一份是任务前状态：提交号、分支、已暂存路径、未暂存路径和未跟踪文件。第二份是当前状态：用相同命令再取一次。第三份是待核实表：记录变化块的意图、是否由此次任务产生以及验证状态。只有文件名的清单不够，同一个文件可能同时包含用户已有工作和工具新增工作。

git rev-parse --show-toplevel
git rev-parse HEAD
git status --short --untracked-files=all
git diff --name-status
git diff --cached --name-status
git diff -- src/parser.py
git diff --cached -- src/parser.py

git diff 默认比较工作区与索引，--cached 比较索引与当前提交，二者应分别检查。未跟踪文件不会自动出现在这两份正文差异里，要按状态清单逐个打开。删除项也必须记录，不要只看新文件。若输出准备共享，先按故障工单脱敏处理路径与内容。

合成例子：中断时留下半个修复

假设任务前 src/parser.py 已有用户对错误文案的修改，工具接着增加了日期校验；中断后又发现 tests/test_parser.py 未跟踪，而锁文件也变了。不要把这四项统称为“Codex 的修改”。可以填写：

路径或变化块	任务前证据	当前发现	下一步
parser.py 文案	基线补丁已有	仍存在	保留用户改动
parser.py 日期分支	基线没有	新增六行	核对空值与非法日期
test_parser.py	基线未跟踪表没有	新文件	打开确认不是空壳
锁文件	任务前无差异	发生变化	追查安装原因

这张表故意允许“归属不明”。没有任务前补丁时，Git 通常只知道文件当前与提交之间的差异，不知道是哪位操作者写的。聊天记录、编辑器历史可以作为辅助证据，但不能把最后修改时间当作作者签名。

按完整性验收，再决定续做

逐块检查新增函数是否有调用方、异常分支是否完整、测试是否真正覆盖任务要求。可以先运行最小的相关测试，再检查失败究竟来自此次变化还是原有环境。把命令、退出码和未运行原因写进第三份清单；“没看到报错”不等于测试通过。

若准备把当前补丁留作恢复点，可导出工作区和暂存区的两份补丁，并另外复制未跟踪产物到明确目录。补丁文件可能包含源码或秘密，按仓库资料的权限保存。二进制、子模块和 LFS 还应保存各自的对象标识或文件摘要，不能期待一份普通文本补丁包含全部资产。

续跑时给工具的是目标和上述清单，要求先确认已落盘变化再继续。不要让它根据上一条“我将修改”推断实际已修改，也别为了获得干净状态直接丢弃所有文件。

常见问题

没有任务前状态怎么办？ 先记录当前状态，把无法确认的块列为待核实；不要补写一份想象中的基线。

状态干净是不是没有工作成果？ 还可能已提交、生成到忽略目录或另一个工作树。核对提交记录与产物路径。

测试失败是否应整批回滚？ 先定位失败与变化的关系，再对明确属于任务的部分处理。共享文件需要保护原有变化。

继续处理相关问题

相关入口：Codex 远程压缩报错分流。

官方依据与核对日期

核对日：2026-10-23。Git diff：默认差异与暂存差异比较对象不同；Git status：状态输出区分索引、工作区与未跟踪文件。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。