1. Codex 说改完了，Git 却一片空白是怎么回事
你让 Codex 改一个登录校验逻辑，它回复「已完成修改，共更新 3 个文件」，你切回终端敲下git status，屏幕上却只有一行nothing to commit, working tree clean。这种「AI 说改了、Git 说没改」的割裂感，几乎每个把 Codex 接进真实项目的人都会撞上一次。
先把结论放前面：绝大多数情况下代码真的被改了，只是你查看 Git 状态的位置，和 Codex 实际工作的仓库、分支或工作区不是同一个。Codex 这类编码 Agent 在运行时，可能自动切分支、自动git add、自动git commit，甚至用 Git Worktree 给每个任务开独立目录。它干活的位置和你眼睛盯着的位置一旦错位，就会出现「改动凭空消失」的错觉。
这篇聚焦三条排查主线：分支、工作区、提交状态。我会给出可直接复制的git status/git branch/git diff检查命令、一份settings.json骨架，以及用 TaoToken 统一 Key 接入 AI 工具后的验证动作。适合正在用 Codex、Cursor、Claude Code 等工具改真实项目，却被 Git 状态搞晕的开发者。读完你能在 2 分钟内定位「代码到底在哪」。
2. 先统一入口：用 TaoToken 管好 Key 再谈排查
排查 Git 之前，有个前置动作值得先做：把 AI 工具的接入入口统一。原因很实际——当你同时用 Codex、Claude Code、Cursor 好几个工具时，每个工具各配一套 Key、各连一个地址，出问题时你连「是哪个工具改的、改到哪」都说不清。入口统一之后，工具行为可预期，排查才有基准。
TaoToken 在这里扮演的是统一接入层：一个 Key 覆盖多个模型与编码工具，地址和密钥集中管理。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api （这个不加 UTM）。你需要在控制台生成 Key，再把它填进各工具的配置里。
具体路径我列一下，方便你按需跳转：
- 生成和管理密钥：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
- 接入文档（各工具配置写法）：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
- 模型对话验证：https://taotoken.net?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
- 长期编码 / Agent 场景：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
- Claude Code 接入说明：https://taotoken.net/doc/claudecode-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite
注意：Key 属于敏感凭据，不要写进会提交到 Git 的文件里。下面给的
settings.json骨架用环境变量占位，就是为了避免 Key 跟着代码一起进仓库——这一点和本篇的 Git 排查主题其实是同一件事：别让不该进版本库的东西混进去。
3. 可复制配置：settings.json 骨架与三条检查命令
3.1 settings.json 骨架
不同工具的配置文件位置不一样，但结构大同小异。下面这份骨架把接入地址和 Key 分离，Key 走环境变量：
{ "ai": { "provider": "taotoken", "baseUrl": "https://taotoken.net/api", "apiKeyEnv": "TAOTOKEN_API_KEY", "model": "your-model-name" }, "agent": { "autoCommit": false, "autoBranch": false, "worktree": false } }这里agent段是排查的关键。autoCommit、autoBranch、worktree三个开关直接决定了 Codex 会不会背着你切分支、提交、开独立工作区。如果你经常遇到「Git 看不到变化」，先把autoCommit和autoBranch设为false，让 Agent 只改文件、不碰 Git 状态，排查范围立刻缩小一半。
设置环境变量（Linux / macOS）：
export TAOTOKEN_API_KEY="你的Key"Windows PowerShell：
$env:TAOTOKEN_API_KEY="你的Key"3.2 三条核心检查命令
第一条，确认仓库根目录。很多人电脑里同时有/project/app、/project/app-copy、/project/app-test，Codex 在app-test改，你在app里查，当然看不到。
pwd git rev-parse --show-toplevelpwd告诉你当前在哪，git rev-parse --show-toplevel告诉你这个目录属于哪个 Git 仓库的根。两个输出对不上，问题就找到了。
第二条，确认分支。Codex 自动建分支后，改动全在新分支上，你盯着main自然一片干净。
git branch --show-current git branch -a--show-current只输出当前分支名，-a列出本地和远程所有分支，方便你找 Codex 可能创建的那个。
第三条，分状态看 diff。这是最容易踩的坑：git diff默认只看未暂存的变化。文件一旦git add，就得换命令。
git status git diff # 工作区未暂存的变化 git diff --cached # 已暂存、未提交的变化 git log --oneline -5 # 最近 5 次提交 git show # 最近一次提交改了什么把这几条按顺序跑一遍，代码在哪个状态基本就清楚了。
4. 验证请求：从仓库到提交的完整排查链
光有命令不够，得知道每条命令对应哪种「假象」。下面按排查顺序走一遍，每条都说明它解决什么问题。
第一步，仓库对不对。
git rev-parse --show-toplevel如果输出是/project/app-test，而你以为在/project/app，那 Codex 的改动一直都在，只是不在你看的地方。
第二步，分支对不对。
git branch --show-current假设输出fix/user-login，而你之前一直在main上找，那切过去就能看到改动：
git checkout fix/user-login git status第三步，Worktree 有没有掺和。一些 AI 工作流用 Git Worktree 给每个任务开独立目录，它们同属一个仓库但对应不同分支：
git worktree list输出会列出每个工作区的路径和对应分支。Codex 可能在/project/app-agent-1干活，你却在/project/app找。
第四步，工作区状态。
git status如果显示nothing to commit, working tree clean，别急着下结论「没改」。往下走。
第五步，暂存区。
git diff --cachedCodex 执行过git add的话，改动全在这里，git diff是看不到的。
第六步，提交历史。
git log --oneline -5 git show如果 Codex 已经git commit，git status干净是正常的，改动进了提交。git show能让你看到最近一次提交具体动了哪些文件、哪些行。
验证接入是否生效。配好 Key 后，先做一次最小验证，确认工具确实通过 TaoToken 在跑：
curl https://taotoken.net/api/v1/models \ -H "Authorization: Bearer $TAOTOKEN_API_KEY"能返回模型列表，说明 Key 和地址都通了。这一步和 Git 排查的关系在于：确认工具行为可预期，你才能相信「Codex 说改了」这句话本身是可信的，剩下的就纯粹是 Git 状态定位问题。
5. 本篇常见错排查
现象一：git status干净，但编辑器里能看到新代码。大概率是文件已git add进暂存区。跑git diff --cached确认。如果暂存区也空，检查是不是看错了同名文件——大型项目里src/config.ts、legacy/config.ts、tests/config.ts同时存在很常见，Codex 说改了config.ts，你打开的可能是另一个。用完整路径确认：
git diff -- src/config.ts现象二：当前分支没变化，切分支后才发现代码在别处。Codex 自动建了分支。用git branch -a找出来，git checkout过去即可。想避免，就在settings.json里把autoBranch设为false。
现象三：Worktree 导致找不到改动位置。git worktree list列出所有工作区，进到 Codex 实际工作的那个目录再看git status。
现象四：任务过程中看到改动，最终却没了。Agent 可能试了方案 A、测试失败、回退、再试方案 B，最后把不需要的改动恢复了。这种情况看最终结果而不是中间操作：如果git status干净且没有新提交，说明中间改动已被回退，属于正常行为。
现象五：git diff输出为空就以为没改。记住git diff只看未暂存变化。已暂存用--cached，已提交用git show。三个命令对应三种状态，别混用。
现象六：Key 或配置写进了仓库文件。如果settings.json里硬编码了 Key 并被git add，它会出现在git diff --cached里。立刻改成环境变量引用，并把该文件加进.gitignore。
6. 让 Codex 主动汇报 Git 状态，从源头省掉排查
排查再熟，也不如一开始就不出错。最省事的做法是在任务指令里加一段要求，让 Codex 收尾时主动交代 Git 状态：
任务完成后请告诉我： 1. 当前工作目录（pwd 输出） 2. 当前 Git 分支 3. 修改了哪些文件（完整路径） 4. 是否已执行 git add 5. 是否已提交，若已提交给出 commit 信息这样你第一眼就知道代码在哪、处于什么 Git 状态，比一句「已完成修改」清楚太多。配合前面settings.json里关掉autoCommit和autoBranch，Agent 的行为就完全在你掌控之内。
如果你打算长期用 Codex 这类工具做编码和 Agent 任务，把接入入口统一到 TaoToken 的 Coding Plan 会更省心，一个 Key 管多个工具，行为可预期，排查有基准：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。接入配置的完整写法在文档里：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。
最后留一个我自己的习惯：每次让 Agent 改完代码，先跑git rev-parse --show-toplevel和git branch --show-current这两条，确认位置和分支，再决定用git diff、git diff --cached还是git show。三步之内定位，比让 Codex 重改一遍快得多，也安全得多——重改一遍反而可能把已经正确的提交搞乱。
