用 Codex CLI 做真实项目时，最烦的一件事是：昨天已经讲清楚需求、读过文件、跑过检查，今天打开终端又要重新交代一遍。如果只是复制上一段聊天记录，既浪费时间，也容易漏掉关键上下文。
现在更稳的做法，是用 Codex CLI 的 resume 能力恢复之前的交互会话。它适合长任务、跨天修 bug、文章发布流程、代码审查和多轮重构。你不用每次从零开始训练 Codex，而是从已有会话继续推进。
本文重点讲 codex resume、CLI 内的 /resume、--last、--all 和 fork 的区别。相邻内容可以先看 AI编程工具专题、OpenAI专题 和 AI智能体与自动化专题。
Codex CLI继续会话解决什么问题？
继续会话的核心价值，是保留已有任务脉络。比如 Codex 已经知道这个仓库的发布脚本、测试命令、AGENTS.md 规则、你刚刚做过哪些改动、哪些命令失败过。恢复会话后，它能基于之前的记录继续工作。
这和重新开一个新会话不同。新会话更干净，但需要重新说明背景；继续会话更连贯，适合还没完成的任务、刚中断的排查、需要追踪上下文的长流程。
如果你刚开始用 Codex CLI，可以先看 Codex CLI安装和登录教程。如果已经在本地项目里跑过任务，再回来学习 resume，会更容易理解它的价值。
三种常见恢复方式
第一种：在终端运行 codex resume。 这是最直接的恢复入口。它会让你选择之前保存的会话，适合你不确定要恢复哪一个任务时使用。
第二种：用 codex resume --last。 如果你就是想继续当前工作目录下最近一次会话，这个命令更快。注意，官方文档说明 --last 默认按当前工作目录选择最近会话，不是全局随便找一个最近会话。
第三种：在 Codex CLI 交互中输入 /resume。 如果你已经进入 CLI，可以直接用斜杠命令打开保存会话选择器。它适合你已经在对话里，但发现需要切回之前某个会话。
–last和–all不要混用
很多人误以为 codex resume --last 会恢复“全电脑最近一次 Codex 会话”。更稳的理解是：默认从当前工作目录相关的会话里找最近一次。这样设计是合理的，因为不同项目的上下文混在一起，很容易让 Codex 读错文件、跑错命令。
如果你确实要跨目录选择最近会话，可以加 --all。但我不建议新手频繁这样做，除非你很清楚要恢复的会话来自哪个项目。
# 选择一个历史会话
codex resume
# 继续当前目录最近一次会话
codex resume --last
# 跨目录查找最近会话
codex resume --last --all对长期项目来说，最好固定从项目根目录打开 Codex。这样 resume、权限、AGENTS.md、脚本路径和 Git 状态都更一致。
什么时候用SESSION_ID？
如果你已经知道某个会话 ID，可以直接指定：
codex resume 00000000-0000-0000-0000-000000000000这种方式适合自动化记录、团队交接或你在日志里保存了明确会话 ID 的场景。普通个人用户不一定每天都要记 ID，但做重要任务时，把会话 ID 写进交接记录会很有用。
比如你用 Codex 维护 WordPress 站点，一次任务可能包括选题、写稿、生成图片、发布、检查。如果中间被打断，记录会话 ID 能让下一次继续时更准确。
恢复会话后第一句话怎么写？
不要一恢复就说“继续”。更好的做法是给 Codex 一个很短的状态校准，让它知道你要从哪里继续。
请先总结当前会话已经完成的步骤、未完成事项和下一步风险，然后继续执行发布后检查。或者：
先读取当前 git 状态和最近一次工具输出，不要立刻改文件。确认上下文后再继续修复测试失败。这类提示能减少“看似恢复了，但其实漏看最新文件状态”的问题。AI 编程不是只靠聊天历史，当前仓库状态同样重要。
resume和fork有什么区别？
resume 是继续原来的会话，适合沿着同一条任务线往下做。fork 是从已有会话分出一个新会话，适合尝试另一种方案，又不想破坏原来的讨论脉络。
举例来说，你让 Codex 修一个前端 bug。原会话已经定位到样式问题。如果你想继续按原方案修，就用 resume；如果你想另开一条路线，让它尝试重构组件，就可以 fork。
这和 Git 分支有点像：resume 像继续当前分支，fork 像从当前进度开一条新路线。真正做项目时，两者都很有用。
哪些任务最适合继续会话？
长时间排查。 比如测试失败、构建失败、依赖冲突、线上页面异常。前面已经试过哪些命令、看过哪些文件，继续会话能保留这些信息。
跨天写作和发布。 对内容站来说，Codex 可能已经读过项目发布规范、站内链接和标签配置。第二天继续，比重新解释更省时间。
多轮代码审查。 初审、修改、复查、补测试往往不是一次完成。继续会话能让 Codex 记住前一次发现的问题和验证结果。
复杂自动化流程。 如果任务涉及 MCP、浏览器检查、截图、表格、WordPress API，恢复上下文能减少重复授权和重复说明。相关权限设计也可以看 Codex CLI权限设置教程。
什么时候不该继续旧会话？
不是所有任务都适合 resume。如果旧会话方向已经跑偏、包含过时假设、项目文件变化很大、或者你要做一个完全不同的新需求，开新会话反而更清楚。
还有一种情况：旧会话里堆了太多失败尝试。继续它可能让 Codex 过度受前面思路影响。这时可以新开会话，只把结论、错误日志和当前目标整理成简短说明。
我自己的建议是：同一任务继续用 resume，不同任务开新会话；想探索替代方案用 fork；想做长期目标管理，可以结合 Codex CLI /goal 工作流。
一个适合个人站长的工作流
- 每天从项目根目录进入 Codex CLI。
- 如果昨天任务未完成，先用
codex resume --last。 - 恢复后先要求它总结已完成、未完成和风险。
- 让它读取当前 Git 状态和最新文件，而不是只相信历史记录。
- 完成后把发布链接、检查结果和会话 ID 写进工作记录。
这套流程特别适合博客维护、SEO 优化、自动化发文、主题调整和跨天排查。Codex CLI 不只是一次性写代码工具，更适合沉淀成长期项目助手。
老达点评
Codex CLI 的 resume 能力，真正提升的不是“少打几个字”，而是让长期任务有连续性。对个人站长和独立开发者来说，很多工作都不是一次完成：选题、写稿、测试、发布、复盘、修 bug，都需要上下文。
但继续会话也不能替代当前检查。每次恢复后，最好先让 Codex 重新看项目状态、命令输出和文件变化。聊天历史负责记住过程，当前检查负责确认现实。两者结合，才是更稳的 AI 编程工作流。
