先说结论：Claude Code 和 Codex 的会话互不相通，换工具时聊过的内容不会跟过去。最稳的办法是让 Claude Code 把进度写进项目根目录的 handoff.md，再让 Codex 只读这个文件接着干。
我们用同一个 AICodeWith Key 实测了一遍：Claude Code 做前一半并写交接文件用了 37 秒，Codex 读文件做完剩下的部分用了 86 秒，测试全部通过。
为什么要写交接文件
Claude Code 的对话记录存在它自己那边，Codex 看不到；反过来也一样。直接在 Codex 里说"接着刚才的做"，它不知道"刚才"是什么。
两边都能看到的只有一样东西：项目里的文件。所以把进度写进仓库里的一个文件，就是最简单、最可靠的共享上下文。
handoff.md 模板
在项目根目录建 handoff.md，按下面六项写。可以直接复制：
# Handoff
## 改了哪些文件
-
## 做到哪
-
## 未完成项
-
## 验收标准
-
## 已知坑
-
## 下一步
1.
每一项写什么：
- 改了哪些文件：新增、修改的文件路径，以及有没有提交 git
- 做到哪：已经能跑的功能，最好写清楚是怎么验证的
- 未完成项：还没做的事，一条一条列
- 验收标准：做到什么程度算完，比如"
python -m unittest全部通过" - 已知坑：踩过的坑、容易误解的地方，这是最省对方时间的一项
- 下一步：按顺序写接手的人第一步做什么
两段提示词
在 Claude Code 里（写完就停）：
把当前进度写到项目根目录的 handoff.md，包含这几项：改了哪些文件、做到哪、未完成项、验收标准、已知坑、下一步。写完就停，不要继续写代码。
在 Codex 里（只读这个文件继续）：
只读项目根目录的 handoff.md，按里面的未完成项和下一步继续做完，达到验收标准后，更新 handoff.md 的进度。
"写完就停"很重要。不加这句，Claude Code 可能顺手把剩下的也做了，交接文件就和代码对不上了。
同一个 Key，两端都接好
两个工具都写全局配置，所有项目通用，用同一个 AICodeWith Key 就行。
Claude Code：打开 ~/.claude/settings.json，在 env 里填上：
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
"ANTHROPIC_AUTH_TOKEN": "sk-你的Key",
"CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK": "1"
}
}
Codex：打开 ~/.codex/config.toml，写入：
model_provider = "aicodewith"
model = "gpt-5.6-sol"
[model_providers.aicodewith]
name = "aicodewith"
base_url = "https://api.aicodewith.ai/chatgpt/v1"
wire_api = "responses"
experimental_bearer_token = "sk-你的Key"
experimental_bearer_token是 Codex 官方配置项，直接把 Key 写在配置里，不用设环境变量。如果你的配置里还有env_key这一行，记得删掉，两者不要同时用。各字段说明见《Codex config.toml 配置指南》和《Codex 接入 AICodeWith》；Claude Code 这边见《Claude Code 如何接入第三方 API》。
实测：一个小项目从 Claude Code 交到 Codex
我们准备了一个很小的命令行待办工具，README 里写了四条要求：add 添加、list 列出、done 标记完成，以及用 unittest 覆盖这三条命令。
第 1 步：Claude Code 做前一半。让它只实现 add 和 list，然后用上面的提示词写 handoff.md。用时 37 秒，模型 claude-opus-5-5。它写出的交接文件里，"已知坑"一项特别有用，比如：
todos.json的路径跟着运行命令时所在的目录走，不跟脚本走- 数据文件路径在导入模块时只读一次，写测试要直接改模块里的变量
python -m unittest要能发现测试，需要tests/__init__.py
第 2 步：Codex 接着做。用上面的 Codex 提示词，它读完 handoff.md 后补上了 done 命令和编号越界的错误处理，写了 7 个测试并全部跑通，最后把 handoff.md 的进度更新成已完成。用时 86 秒，模型 gpt-5.6-sol。
全程没有在两个工具之间复制任何聊天记录，靠的只有这一个文件。
实测中 Codex 还主动用上了交接文件里的坑：它直接建了 tests/__init__.py，测试里也是改模块变量而不是环境变量。这正是"已知坑"一项的价值。长期规则和本轮进度分开放
交接文件只放这一轮的进度。项目长期不变的规则，放到各自的说明文件里：
| 放什么 | 放哪里 |
|---|---|
| 长期规则：代码规范、测试命令、目录约定 | Claude Code 读 CLAUDE.md，Codex 读 AGENTS.md |
| 本轮进度：做到哪、还差什么 | handoff.md |
这样 handoff.md 可以每轮重写，不会越来越长。CLAUDE.md 怎么写见《CLAUDE.md 写法指南》。
如果交接流程固定下来，可以把"写 handoff.md"做成一个 Skill，以后输入一个命令就能生成，做法见《Claude Code Skill 怎么用》。
另一种交接方式：GitHub Issue
团队协作或者跨机器时，也可以把同样六项内容写进一个 GitHub Issue，让接手的工具去读这个 Issue。好处是有记录、能讨论；缺点是需要工具能访问 GitHub。个人在本机换工具，handoff.md 更省事。
常见问题
handoff.md 要提交到 git 吗？
看情况。只是自己换工具，可以加进 .gitignore；需要同事接手，就提交上去。
能反过来从 Codex 交给 Claude Code 吗？
能。把两段提示词互换一下就行，文件格式不用变。
Codex 读完 handoff.md 还是理解错了怎么办？
多半是"验收标准"写得太虚。改成能直接检查的条件，比如"python -m unittest 全部通过"，而不是"功能完善"。
两个工具同时改同一个项目可以吗？
不建议。同一时间只让一个工具改代码，交接完再换，免得互相覆盖。
