CODEX 为什么会自动疯狂创建分支？排查思路与解决方案

最近在折腾项目的时候，遇到一件挺让人头疼的事儿：打开代码仓库一看，好家伙，分支列表里密密麻麻全是各种奇怪的分支，有的带时间戳，有的带乱码，就像家里来了个不听话的熊孩子，把东西扔得到处都是。如果你的工具是 CODEX，并且你也遇到了这种“自动乱开分支”的情况，别慌，这其实是个比较常见的配置或逻辑问题，咱们今天就盘一盘到底是哪儿出了岔子，以及怎么把它治好。

一、这锅到底谁背？先自查配置

绝大多数情况下，工具不会无缘无故地发疯。CODEX 作为一个强大的辅助工具，它的每一个动作通常都是由具体的“指令”触发来的。如果它不停开分支，大概率是以下这几个环节出了问题。

1. 自动化工作流的误判 现在的 CI/CD 或者自动化任务都喜欢搞个“Branch Strategy”（分支策略）。比如你设置了一个监听器，每当有代码提交，或者每隔 10 分钟检查一次更新，如果配置里勾选了“Always create a new branch for deployment”（总是为新部署创建分支），那它就会老老实实地执行你的命令，疯狂开分支。

• 排查点：检查 CODEX 的关联配置文件（通常是 YAML 或 JSON 格式）。看看有没有类似 on: push: branches: ["**"] 这种过于模糊的触发条件，或者是 git checkout -b 这种硬编码的脚本。

2. IDE 插件或本地钩子的幽灵 有时候问题不在服务器，而在你的电脑上。如果你安装了 CODEX 相关的 IDE 插件，或者是配置了 pre-commit、post-commit 钩子，可能在你保存文件的一瞬间，插件就自动帮你拉了个新分支试图去做备份或分析。

• 排查点：暂时禁用相关插件，或者在 .git/hooks 目录下清理一些怀疑对象的脚本，观察一下是否还会继续开分支。

二、权限管理：是不是它“手伸太长”？

还有一种可能是权限范围给得太大了。如果你的 CODEX 配置中绑定的 Token 拥了 Repository 的写入权限，甚至是 Admin 权限，那么一旦它内部的判断逻辑出现一点小 Bug，它就有能力直接在你的远程仓库上“为所欲为”。

• 解决方案：去你的代码托管平台（比如 GitHub/GitLab），重新审视这个机器人的 Personal Access Token (PAT)。如果不需要写库，就只给 Read 权限；如果确实需要写入，尽量限制它只能操作特定的 Protected Branch，或者禁止它创建非命名规范的分支。

三、深度排查：看“作案现场”

如果配置和权限看了都没问题，这时候就得看日志了，这是最能还原真相的物证。

• 操作建议：开启 CODEX 的 Debug 日志模式。不要只看 Info 级别的日志，要看 Error 和 Warn 级别的输出。重点留意是否有 Git command failed 后紧接着 retrying with new branch 的报错。这通常意味着它执行某操作失败了，然后为了“兜底”，傻乎乎地开新分支重试。

四、终极兜底方案

如果实在查不出原因，又不想让仓库继续被污染，可以用以下几招“止血”：

1. Branch Protection Rules（分支保护规则）：在代码托管平台设置规则，禁止除了特定人员（比如你自己）和特定 CI 系统外的任何人（包括 CODEX）创建新分支。
2. 定期清理脚本：写一个简单的 GitHub Action 或 GitLab Pipeline，每天凌晨扫描并删除所有匹配 codex-temp-* 这种命名规则的僵尸分支，治标治本。

总结

遇到工具“自作主张”确实很搞心态，但只要从“触发条件”、“权限控制”和“运行日志”这三个方向入手，基本都能揪出病灶。希望这篇排查思路能帮你解决掉 CODEX 乱开分支的烦恼，还仓库一个清清爽爽的提交列表。