会提交，但通常不会自动合进主干
Codex 改代码时，是在一个独立分支（或工作副本）上操作，并把改动提交到那条分支。关键点是：它提交不等于它合并。默认情况下合并回 main / master 这一步要你来做——你先在 PR 里看 diff、跑测试、确认没问题，再合。也就是说，它最多把「改好的代码」放到一条待你审核的分支上，不会一声不响就推到主干。
为什么还会有「乱 commit」的担心
第一，如果你把 CLI 接到自己的仓库、且给它写权限，它确实能在本地分支上提交。第二，云端任务跑完，改动落在它创建的分支，你忘了 review 就合，也算「乱」。第三，自动模式开太猛时，它可能一个任务建好几条分支、提交好几轮。这些都不是它「恶意」，而是权限和流程没设好。
防乱 commit/push 的 4 个设置
- 保护 main：在 GitHub / GitLab 设分支保护，禁止直接 push、要求 PR + review。就算 Codex 想推也推不进去。
- 给最小权限：连接仓库时只给「写分支、开 PR」的权限，不要给「合 PR、推主干」的权限。
- 一个任务一条分支：让它每次在独立分支工作，别在共享分支上累加提交，review 时一眼看清这一轮改了什么。
- 关掉自动合并：任何「改完自动合」的开关都保持关；合并这一下永远留给你。
跑完之后怎么收尾
任务结束，先让 Codex 给自己写一段改动说明（改了哪些文件、为什么、怎么测），你对照 diff 看三件事：有没有动到不该动的配置、测试是不是真过了、提交信息是否清楚。都过了再合。合完把分支删掉，保持仓库干净。
已经提交错了怎么办
别急，提交都在分支上、没合进主干就都可控。让 Codex 列一下这次的提交，你挑要回退的用 revert 或把分支重置到合并之前；实在理不清，直接删分支重开任务最干净。只要 main 受保护，最坏情况也只是多一条待清的分支，不会污染主干。
把「它能提交」和「它能合并」分开看，就不会慌。提交是它帮你省的事，合并是你该把的最后一道关。
