Claude Code 被封，旧项目怎么办？让 Codex 接手

温馨提示：若页面不能正常显示数学公式和代码，请阅读原文获得更好的阅读体验。

作者：艾米丽 (连享会)
邮箱：lianxhcn@163.com

• Title: Claude Code 被封，旧项目怎么办？让 Codex 接手
• Keywords: Claude Code, Codex, 项目迁移, Git, AGENTS.md, 项目交接, Claude Code 日志
• 提要：本文介绍了如何在 Claude Code 暂时不可用的情况下，让 Codex 低成本接手旧项目，包括迁移核心资产、建立稳定检查点、进行项目接管审计等步骤。文末提供了 项目交接工具包 的下载链接。

这几天，陆续有读者询问同一个问题：Claude Code 暂时不能用了，但过去几周一直由它维护的讲义、论文复现、数据分析项目和课程网站还没有做完，换成 Codex 后是不是要从头解释一遍？

通常不需要。Agent 可以中断，已经形成的项目不必重来。真正影响接管成本的，不是旧对话还能不能续上，而是项目状态、工作规则和后续任务有没有留在本地。

这个话题还涉及 Skills 怎样在 Claude Code、Codex 和其他 Agent 之间共享。相关的安装、分层管理和 Router 方案，连享会已经在 Agent Skills 指南系列 中集中讨论，本文不再重复。本文先处理更紧迫的问题：怎样让 Codex 低成本接手一个已经被 Claude Code 深度维护的旧项目。下一篇再讨论怎样建立不依赖单一 Agent 的长期工作架构。

1. 真正需要迁移的是什么

很多人把 Agent 的工作理解成一段很长的对话：旧对话断了，新 Agent 就不知道前面发生过什么。

这更像网页聊天的使用方式。Claude Code 在本地项目中持续工作以后，真正有价值的内容通常已经分散在几个位置：

• .qmd、.md、.py、.do、.ipynb等正式源文件；
• _quarto.yml、pyproject.toml、环境配置和构建脚本；
• README.md、CLAUDE.md、任务说明和项目笔记；
• Git 提交历史；
• 图片、表格、数据接口、测试结果和发布产物；
• Claude Code 的自动 Memory、会话日志和账号导出数据。

前五类资料主要描述项目的当前状态，最后一类主要记录工作过程。二者不能等量齐观。

例如，一章讲义在讨论过程中可能形成过五套结构，最后只采用一套。完整聊天日志会保留五套设想，当前文件和 Git 历史则告诉 Codex 最终留下了什么。如果新 Agent 从头通读全部日志，反而可能重新引入已经放弃的方案。

因此，旧项目的接管顺序应当是：

当前文件→Git 历史→项目规则→定向查询日志当前文件→Git 历史→项目规则→定向查询日志

当前文件回答「现在是什么」，Git 历史回答「最近改了什么」，项目规则回答「接下来应当怎样改」，日志只负责补充少数无法从项目本身判断的历史决策。

简言之，迁移的重点不是恢复原来的聊天现场，而是重建可继续工作的项目上下文。

2. 接管前：先固定当前版本

不要一打开 Codex 就让它继续写下一章。接管之前，先建立一个能够随时返回的稳定检查点。

2.1 提交并推送当前版本

通过 GitHub Desktop、VS Code 或命令行提交，形成的都是标准 Git 提交。GitHub 官方文档也明确说明，本地版本控制由 Git 负责，git push只是把本地提交同步到远程仓库。因此，通过 GitHub Desktop 创建的历史，Codex 可以正常读取和比较。GitHub 官方说明

在 GitHub Desktop 中检查左侧的Changes。如果还有未提交修改，建议先建立一次接管前检查点：

checkpoint: Claude Code 工作结束及 Codex 接管前版本

描述可以写成：

当前项目已完成阶段性定稿。 此提交用于保存 Codex 接手前的稳定版本。

提交后再点击Push origin。本地提交已经足以供 Codex 查看；推送以后，GitHub 上也有一份相同的稳定版本。

2.2 再做一次物理备份

Git 能恢复绝大多数修改，但对于已经定稿的讲义、论文复现或课程网站，我仍建议完整复制一次项目文件夹。例如：

D:\github_lianxh\PXa2026a

备份为：

D:\github_lianxh\PXa2026a_backup_20260719

复制后确认备份目录中保留了隐藏的.git文件夹。Git 负责精确比较和版本回退，物理备份用于处理误删目录、配置损坏，或者用户暂时不熟悉 Git 恢复操作的情况。

2.3 分支不是强制要求

熟悉 Git 的用户可以新建codex-expansion分支，让 Codex 在独立分支中工作。对分支操作不熟悉的用户，没有必要为了迁移临时增加一套新流程。

继续在main分支工作也可以，但要增加三个约束：

• 每轮只处理一个章节或一组紧密相关的文件；
• Codex 不得自行执行git commit和git push；
• 用户验收后，再通过 GitHub Desktop 提交。

对应的工作流程很简单：

Codex 修改 → 用户检查文件或网页 → GitHub Desktop 查看 Changes → 满意后 Commit → Push origin

对于单人维护的讲义和研究项目，这种方式通常已经足够稳妥。

2.4 Claude 数据不要混入项目仓库

账号导出的conversations.json、本地.claude目录和会话日志不要复制进正式项目。这些文件可能包含本地用户名、绝对路径、邮箱、服务器地址、Token、付费账号信息和大量与项目无关的内容。

更合理的安排是：

项目目录：正式成果、代码、配置和项目规则 备份目录：Codex 接管前的完整项目副本 私有归档：Claude 导出数据、本地 Memory 和原始日志

备份追求的是可恢复性，不是把所有历史资料塞进仓库。原始日志放在项目外部，需要时再定向读取。

3. Codex 第一轮只做审计

新 Agent 接手旧项目时，最常见的错误是直接下达具体任务，例如「继续润色第 4 章」或「增加一章固定效应」。Codex 可以立即修改，但它还不知道整本讲义的结构、已有规则和发布方式，容易产生局部顺畅、整体失调的结果。

更好的第一轮任务是项目接管审计。这一轮只允许读取和分析，不改正文。

温馨提示：若页面不能正常显示数学公式和代码，请阅读原文获得更好的阅读体验。