侧栏冒出不是 Codex 改的文件？先把 diff 面板切到 Last turn 视图

2026-08-09

先说结论：Codex（OpenAI Codex）的 diff 面板里出现”不是它改的文件”，官方文档把这归到面板展示范围的问题，而不是模型越权改文件。官方给出的原因是：项目在一个 Git 仓库里，面板展示的是全部 Git 状态变更；给出的做法是把 diff 面板切到 “Last turn” 视图，只看 Codex 本轮的改动。

这条排查很值得单独写一篇，因为它的误判代价特别高。你一旦认定”AI 把我的文件动了”，接下来的动作通常是 revert、是把沙箱收紧、是干脆不用了——而真实情况可能只是面板在如实显示你自己三天前留下的半成品。下面按排查文章的老规矩走：现象 → 怎么确认是这个问题 → 官方处置 → 处置后怎么验证 → 什么情况说明不是这个原因。

一、现象是什么样的

典型表述是这样的：你让 Codex 做一件范围很窄的事，比如改一个函数；结果 diff 面板里列出的文件数量远超预期，里面还夹着配置文件、锁文件、甚至一些你记得自己动过但没提交的东西。

关键特征有两个：

多出来的文件，往往是你”本来就改过但没提交”的那批。不是随机的、不是模型凭空生成的。
多出来的文件通常和本轮提示词毫无语义关联。如果模型真跑偏去改别的地方，改动一般还是围着你的任务转；而这里冒出来的是完全另一条线上的东西。

对上这两条，就有很大概率是范围显示问题，而不是行为越界问题。

二、怎么确认是这个问题

官方给的原因是”面板展示的是全部 Git 状态变更”。既然原因落在 Git 上，那判定就交给 Git 自己来做——注意，下面这几条是标准 Git 命令，不是 Codex 提供的排查命令，我把它们列出来是因为官方定位的成因就在这里，用 Git 去交叉核对最直接。

在项目根目录跑：

# 1. 看当前工作区到底有多少变更（含未暂存、已暂存、未跟踪）
git status --short

# 2. 看未暂存改动涉及哪些文件、各改了多少行
git diff --stat

# 3. 看已暂存但未提交的那一层
git diff --cached --stat

# 4. 最近几次提交，确认你以为的"干净基线"到底停在哪
git log --oneline -5

Windows 与 macOS/Linux 在这几条上没有差别，Git Bash、PowerShell、终端里都一样。

判定标准很简单：把 git status --short 列出的文件集合，和面板里让你困惑的那个集合对一下。

两个集合基本重合 → 基本可以确认就是这个问题：面板显示的是整个工作区的 Git 状态，不是本轮增量。
面板里的文件是 git status 集合的子集，但仍然多于你的预期 → 大概率还是同一个问题，只是你对自己工作区有多脏估计得太乐观了。用 git diff --stat 逐个看一眼改动内容，多半能认出是自己什么时候留下的。
面板里出现了 git status 根本没列出来的文件 → 那就不是这条了，跳到第五节。

顺带一提，codex doctor 的 Environment 分组里有一项就是 git（本机在 codex-cli 0.147.0（Windows 11）上跑 codex doctor --summary，这一项显示的是 git 版本信息）。它只能告诉你 Git 环境本身是通的，不会告诉你面板显示了哪些文件，别指望用 doctor 定位这个问题。

三、官方给的处置

官方文档给的做法是：把 diff 面板切到 “Last turn” 视图，这样只看 Codex 本轮的改动。

这里必须交代清楚边界：这个视图切换属于桌面应用侧的操作，我们没有实测过桌面应用，上面这句是官方文档口径。官方排查页里这一整组条目（侧栏项目管理、归档聊天、聊天排序、字体设置等）绝大多数都是面向桌面应用的，写这类文章最容易犯的错就是把桌面应用的界面操作套到 CLI 上去讲，我这里不这么干。

“Last turn”这个措辞本身值得留意一下：官方的原话是”只看 Codex 本轮的改动”，用的词是”本轮”，不是”整个会话”。至于一个任务来回追问好几轮的时候，这个视图具体包含哪几轮的改动，官方文档里没有说明，我们也没有实测过桌面应用界面，所以这里不替它下结论。你只要记住一件事就够用了：想看全会话范围、或者跨越多轮的全部改动，仍然要靠 Git 侧的手段——本文第二节那几条 git 命令，才是范围最明确、最不依赖界面口径的那把尺子。

四、处置后怎么验证

切完视图之后，别只是”感觉清爽了”就算完，做一次闭环核对：

数文件。切换后的文件列表，应该明显短于 git status --short 的输出。如果两者依然一样长，说明视图没切成功，或者你的工作区本来就干净、这两个集合天然重合（后一种情况你其实一开始就不会遇到这个困惑）。
逐条对任务。切换后剩下的每个文件，都应该能和你这一轮提出的要求对上号。对不上号的那几个才是真正要追的线索。
反向确认一次。把之前让你困惑的某个文件挑出来，用 git diff -- <那个文件> 看具体改了什么。如果改动内容是你自己的旧笔迹（半行注释、调试用的打印、临时改的配置），那这条排查就结案了。

如果你想要一个更硬的验证方式，可以在下一次开工前先把工作区弄干净——提交、或者暂存起来，让 git status --short 输出为空，再让 Codex 动手。基线干净的时候，“全部 Git 状态变更”和”本轮改动”就自然重合了，面板显示什么范围都不会再让你困惑。这条是我自己的习惯做法，不是官方要求，但它能把这类判断题直接消掉。

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

以下几种情况，说明你遇到的不是”面板范围”问题，别在这条路上继续钻。

其一：项目根本不在 Git 仓库里。 官方给这条排查限定的前提就是”项目在 Git 仓库里”。不在仓库里，“展示全部 Git 状态变更”这个解释就不成立。补充一个 CLI 侧的旁证：在 codex-cli 0.147.0（Windows 11）上，codex exec 有一个 --skip-git-repo-check 选项，官方说明是”允许在非 Git 仓库里运行”——反过来说明默认情况下 Codex 对”是不是 Git 仓库”是有判断的，非仓库场景是需要显式放行的另一条路径。

其二：会话起错了执行目标。 官方排查里另有一条：会话可能起在 Local / Worktree / Cloud 里的错误目标上。官方给的做法是取消运行后，在 composer 里按上方向键找回原来的提示词（同样是桌面应用口径，非本机实测）。这条之所以和本篇相关：如果改动落在了另一个目标上，你在当前这个位置看到的”多出来”或者”少了”，成因完全不同，切视图没用。

其三：你在 worktree 里。 官方在 worktree 相关的排查条目里明确说过，worktree 是另一个目录、继承了 Git 文件。目录不同，git status 的结果自然不同。如果你在一个目录里查 git status、面板对着的却是另一个 worktree 目录，两边集合对不上是必然的，这时候先把”我到底在哪个目录”搞清楚，比切视图重要。

其四：CLI 和桌面应用是两个版本。 官方排查里有一条专门讲这个：某个功能 CLI 有、桌面应用没有，原因是两个面的 Codex 版本不同。官方给的分别查版本的办法是 codex --version（CLI），以及 macOS 上的 /Applications/Codex.app/Contents/Resources/codex --version。Windows 侧对应的可执行文件路径，官方这条排查里没有给，我也不替它猜。

版本这件事必须以实时输出为准，别用记忆里的号。本机在采集数据时就撞上过：同一台机器、开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后再执行同一条命令变成了 codex-cli 0.147.0，而 which -a codex 全程只有一个可执行文件。Codex 有自更新能力（config 里的 check_for_update_on_startup 默认为 true），所以”昨天看到的版本号和今天不一样”是正常现象。排查任何和版本有关的差异，第一步都是当场跑一次 codex --version。

其五：面板里出现了 git status 完全没有的文件。 这已经超出了”展示范围”能解释的边界。这种情况事实材料里没有对应条目，我不会给你一个听起来很像那么回事的解释——去查你自己的工具链（编辑器插件、格式化钩子、构建产物是否被写进了工作区）比套用这条排查更靠谱。

六、CLI 侧：与其”看全部再挑”，不如一开始就限定范围

桌面应用那边靠切视图解决，CLI 侧其实有一组更直接的东西——在发起动作时就把范围钉死。以下都是本机在 codex-cli 0.147.0（Windows 11）上从 --help 里读到的原文选项：

codex review 有三个互相独立的范围限定方式：

# 只评审已暂存、未暂存和未跟踪的改动
codex review --uncommitted

# 与指定基线分支比较
codex review --base main

# 只评审某个 commit 引入的改动
codex review --commit <SHA>

这三个选项的存在本身就说明了一件事：“要看哪一段改动”是需要显式表达的，工具默认并不知道你心里那个”本轮”指的是哪一段。桌面应用侧的 “Last turn” 视图，和 CLI 侧的这三个开关，解决的是同一类问题的两个面。

另外还有一个和”本轮改动”直接相关的子命令，codex apply（别名 a），官方说明是把 Codex agent 产生的最近一次 diff 以 git apply 的方式应用到本地工作树。注意它的措辞是 latest diff——同样是”最近一次”的概念，而不是”全部”。

需要说明的是，我们这次采集没有发起过任何模型对话请求，上面这些是 --help 的原文与选项语义，不是”我跑了一遍它是这个效果”。真正下手前，仍然建议先在一个干净的分支上试，Git 的可回退性才是你这里最实在的后路。

七、一句话记法

看到不该出现的文件，先问三个问题：我在哪个目录？我的工作区本来干净吗？我看的是哪个范围？ 三个问题里但凡有一个答不上来，就先别下”AI 乱改我代码”的结论。这条排查的官方成因是显示范围，处置是切到 “Last turn”，而 Git 侧的 git status --short 永远是那个能给你标准答案的裁判。