Agent · AI 工程 · 工具协作

Claude Code × Codex 双开一个项目

同一个项目能不能同时用 Claude Code 和 OpenAI 的 Codex CLI？可行，两边官方都给了配套——但不是装上就能跑。有两道坎必须先迈过：指令文件互不相认（Claude 只读 CLAUDE.md，Codex 只读 AGENTS.md），以及两个 agent 不能同时写一个工作区。本文以 Akke 仓库的真实现状为例，把落地路径讲清。

篇幅 5 章 · 约 10 分钟主线 Akke 仓库现状 + 两家官方文档 调研日期 2026-07-13 · 版本类信息 30 天后需重核

先说结论：双开可行，且已经是社区常见做法——两个工具用不同公司的模型，互相 review 时能避开"自己审自己"的盲区；OpenAI 甚至官方出了一个装在 Claude Code 里的 Codex 插件。但"可行"不等于"零成本"：Akke 的项目知识大量写在 Claude Code 专属机制里（CLAUDE.md、24 个 skills、memory 目录），Codex 一条都读不到，裸着进来等于一个不看文档的新同事。

证据分级 · 文中结论按来源强度标注：A 官方文档 B 多个独立来源一致 C 单一来源 / 社区印象。带 C 标的"谁擅长什么"类说法是方向性印象，不是铁律。

Section 01 · 现状

2026 年年中，这两个工具各长什么样

Claude Code 团队天天在用，不展开。Codex 这边如果你的印象还停留在 2025 年的"research preview"，那已经全过时了：现在是开源 Rust CLI（2026-07 最新版 v0.144），ChatGPT 各订阅档位都含 Codex 用量（也可 API key 按量付费），默认模型是 GPT-5.6 系列（CLI 默认 gpt-5.6-sol），CLI / IDE 扩展 / 云端并行环境（codex cloud）多形态一体。A

关键差异对照

维度	Claude Code	Codex CLI
项目指令文件	只读 `CLAUDE.md`（支持 `@import`）	只读 `AGENTS.md`（git root → cwd 逐层拼接，默认 32 KiB 上限）
权限模型	按工具 / 按命令审批（allow/deny 规则 + hooks），粒度在"哪条命令"	OS 级沙箱（macOS Seatbelt / Linux bwrap），沙箱内全自动，越界才审批，粒度在"文件系统 / 网络边界"
网络	默认可联网	沙箱默认断网（`network_access` 需显式打开）
git 行为	默认不主动 commit	同样默认不 commit；改动留在 working tree
扩展机制	skills / hooks / subagents / MCP / plugins	profiles / MCP（一等公民）/ plugins / `codex cloud`
保护目录	—	沙箱内 `.git`、`.codex`、`.agents` 强制只读

来源：两家官方文档（code.claude.com / developers.openai.com）A

心智模型差异要先适应 · Codex 的默认推荐档（Auto = workspace-write）在沙箱边界内删文件、改文件都不会问你，只有出边界（联网、写 workspace 外）才弹审批——比 Claude Code 的默认体感"更放手"。反过来它默认断网，跑需要拉依赖 / 调外部 API 的任务时经常要显式开 network_access。A

Section 02 · 第一道坎

指令文件互不相认：Codex 进 Akke 是"失明"状态

两个事实：Claude Code 至今不原生读 AGENTS.md（官方 memory 文档原话："Claude Code reads CLAUDE.md, not AGENTS.md"；对应 feature request #6235 开了近一年仍无排期）A；Codex 也不原生读 CLAUDE.md A。网上流传的"Claude Code 会自动 fallback 读 AGENTS.md"的说法是假的。B

这对 Akke 意味着什么？看仓库现状：

Akke 仓库根目录 · 2026-07-13 实查

CLAUDE.md    ✓ 存在（172 行，含高危路径 PR 规则 / migration 命名 /
               eval key 花费隔离 / RLS 三层防御 …… 全部项目军规）
AGENTS.md    ✗ 不存在
.codex/      ✗ 不存在

也就是说，今天直接在 Akke 里跑 Codex，它一条项目规则都看不见：不知道 migration 要用时间戳前缀、不知道评测必须走 eval key 隔离花费、不知道哪些路径必须走 PR。这些规则每一条背后都是真实事故换来的。

四种打通方案

方案	做法	适合	证据
① import 桥接	AGENTS.md 当唯一真源；CLAUDE.md 只剩一行 `@AGENTS.md`（+ 少量 Claude 专属段）	官方推荐的长期解；跨平台、随 repo 走，队友零配置	A
② symlink	`ln -s AGENTS.md CLAUDE.md`	零维护但没法写 Claude 专属内容；Windows 有权限坑	A
③ Codex fallback	`~/.codex/config.toml` 里配 `project_doc_fallback_filenames = ["CLAUDE.md"]`，让 Codex 直接读 CLAUDE.md	老仓库零改动、最快见效；但配置只在本机生效，每人都要配一次	A
④ 双文件各写各的	CLAUDE.md 和 AGENTS.md 独立维护	不建议——最高频踩坑是改了一份忘另一份，两个 agent 对同一约定行为不一致且极难排查	B

Akke 的务实路径 · 第一步先用方案 ③（一行 config，当天能跑）验证 Codex 值不值得留下；确认要长期双开再做方案 ① 的正式拆分。注意两点：Codex 拼接指令有默认 32 KiB 上限，超出部分静默截断；Akke 的 CLAUDE.md 里引用的 docs/claude-memory/ 记忆体系 Codex 不会递归去读，重要规则必须写在指令文件正文里。A

Section 03 · 第二道坎

同一个 working tree，同一时刻只能有一支笔

两边都默认不 commit、都把改动留在 working tree——这恰恰是危险所在：让两个 agent 并行写同一个目录，等于两个人共用一块白板同时写字。社区反复报告的具体故障模式：B

静默覆盖 — A、B 同时编辑同一文件，后写者直接覆盖前者，没有任何告警；agent 还会基于过期的文件视图继续改，产出逻辑错乱的"混合 diff"
.git/index.lock 竞争 — 两个 agent 同时 git add/commit 抢索引锁，崩溃后残留 lock 文件阻塞后续所有 git 操作
混合 commit — 一边爱用 git add -A（Codex 有此习惯的公开 issue），会把对方未审的改动一起打包进自己的 commit，署名和实际作者对不上
lockfile 大 diff — 两边各自加依赖、各自重生成 lockfile，merge 时几乎每行都冲突
覆盖未提交工作 — Codex 有过 git restore 覆盖用户未提交改动的数据丢失 issue（GPT-5.2 时期，#8213 / #8643）——交替跑两个 agent 时这类风险被放大

Akke 有前科 · 团队只跑多个 Claude Code 会话时就发生过工作区互抢：HEAD 几分钟内四次易手、落后 commit 数乱跳（详见《PR 与 Git Worktree》）。再加一个不同品牌、不同权限模型的 agent 进来，只会更热闹。

两种安全姿势

串行同 tree（一写一审）

同一时刻只有一个 agent 在写：Claude 写完 → Codex review 审未提交 diff（或反向）。零覆盖风险、零额外设施，日常最常用。

并行 worktree（各写各的）

每个 agent 一个 worktree + 独立分支，冲突从"工作时静默发生"变成"merge 时被 git 正常检测"。Akke 已有现成封装 scripts/new-worktree.sh。

并行 worktree 也不是银弹，老三样要各自独立：依赖要各装一份（node_modules 不共享）、构建缓存别共享（.next/ 等）、.env 各配各的；且任务要按 feature 边界切，别让两个 agent 从不同方向碰同一批文件——否则 merge 时照样炸。B 另外 CLAUDE.local.md 这种 gitignored 的本地指令不会跟着 worktree 走，跨 worktree 共享个人偏好要改用 @~/.claude/xxx.md import。A

Section 04 · 协作模式

从轻到重的四种配合，多数团队从"互审"开始

双开最大的收益不是"多一双手"，而是多一个不同分布的脑子：让模型 review 自己写的代码，等于从产生错误的同一个分布里再采样一次；换一家的模型来审，相关盲区小得多。B 按投入从轻到重：

模式	怎么跑	备注
① CLI 互审	Claude 写完，同目录跑 `codex review` 审未提交 diff；或反过来	零设施，串行安全；Codex review 看的是整个未提交状态，正好覆盖 Claude 留下的改动
② 官方插件	Claude Code 里装 OpenAI 官方的 `codex-plugin-cc`：`/codex:review` 对抗审查、`/codex:rescue` 卡住的 bug 移交 Codex	OpenAI 官方维护、28k+ star；复用本机 codex 登录，需 ChatGPT 订阅或 API key A
③ PR 交叉审	GitHub PR 上 `@codex review` 触发 Codex 云端审（只报 P0/P1）；Anthropic 侧挂 `claude-code-action`	Akke 的 CI 已经挂了 claude-code-action，这条路径接入成本最低；Codex 审 PR 时会遵循仓库 AGENTS.md——又回到第 02 章 A
④ worktree 并行分工	两个 agent 各占 worktree，按 feature 切任务并行推进	吞吐最大、管理成本也最大；见第 03 章的隔离三件套

社区怎么分工（印象，非铁律）· 对 21+ 个 Reddit 线程、202 条明确表态的聚合分析显示：约四分之一的实践者主张双工具栈；被引用最多的循环是 Claude 规划拆解 → Codex 按 spec 精确实现 → Claude 审前端/可读性 → Codex 审后端逻辑。印象上 Codex 强在后端逻辑、重构、spec 忠实度，Claude 强在规划编排、前端、可解释性。样本偏重度用户，方向性参考即可。C

Section 05 · 落到 Akke

Codex 能接什么活，不能接什么活

Akke 和一般代码仓库有个关键不同：它的日常运转大量依赖 Claude Code 专属机制——24 个项目 skills（发 DM、跑反评、图文发布、扩源、日报……）、4 个 slash commands、symlink 进仓库的 docs/claude-memory/ 记忆体系、/loop 长任务编排。这些 Codex 一概读不到、跑不了。

所以在 Akke 里，Codex 的合理定位是"纯代码工 + 第二意见"，而不是全能替身：

适合给 Codex 的活

spec 明确的功能实现、重构、写测试；review Claude 写的后端逻辑 / cron / 状态机代码；PR 层 @codex review 当第二道门禁。

留给 Claude Code 的活

一切走 skills 的运营链路（发 DM、云电脑、图文、日报）、memory 读写、/loop 编排、跨仓库部署验证——这些知识只在 Claude 侧存在。

成本上，双开基本意味着两份订阅（Claude 侧 + ChatGPT 侧；Codex 也可以 API key 按量付费）。社区的普遍建议是：先用手头已有的档位跑互审模式，确认有具体的、说得出的瓶颈（比如用量顶到限额、某类任务明显更适合另一边）再升配。B

落地清单（按顺序做）

打通指令文件 — 短期：~/.codex/config.toml 配 project_doc_fallback_filenames = ["CLAUDE.md"]；长期：AGENTS.md 做唯一真源 + CLAUDE.md 一行 @AGENTS.md。盯住 32 KiB 上限
约定"一支笔"规则 — 同一 working tree 里两个 agent 只能串行；要并行就各开 worktree（scripts/new-worktree.sh），按 feature 边界切任务
从 PR 交叉审起步 — Akke 已挂 claude-code-action，只需再接 @codex review，投入最小、见效最快
format 收敛到 git 层 — 两个工具共用同一套 pre-commit / husky 配置，别在各自的 hook 里各跑各的 formatter，否则同一文件被来回重排 B
高危路径规则两边同步 — CLAUDE.md 里"哪些路径必须走 PR"的军规，打通指令文件后 Codex 才看得见；在此之前不要让 Codex 碰 migrations/、api/cron/、llm/

双开可行——前提是把"项目怎么干"写在两个 agent 都读得到的地方，并保证同一时刻只有一支笔在写工作区。