codex会话过长会导致响应变慢、指令被忽略、关键变量丢失或报错“context_window_exceeded”；应立即用/compact压缩、按任务关系选用/side/fork/new/clear切换、分块读取大文件并设计handoff接力点。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Codex会话记录上下文过长会导致响应变慢、指令被忽略、关键变量丢失，甚至直接报错“context_window_exceeded”，无法继续输入任何新指令。
立即释放空间：用 /compact 压缩当前会话
这一步操作起来很简单，直接在当前会话里输入：
/compact
Codex 会把冗长的对话历史自动提炼成语义摘要，用几百字的总结替换掉几千字的原始记录。压缩后模型仍能记住任务目标和关键约束，但不再逐字复述你之前问过的每个细节。【压缩不可逆，且可能丢失行号、变量名等精确信息】。执行后建议立刻输入 /status 查看 token 使用量是否明显下降。
切换任务线：/side、/fork、/new、/clear 四选一
先问自己：接下来要做的事，和当前任务是什么关系？
方法一：临时插问，不打断主线 → /side
比如正在重构订单服务，突然想确认 Redis 连接池配置是否合理，就输入 /side 检查连接池参数。支线回答完自动回到原任务，历史不混入主线。
方法二：保留当前进度，探索另一套方案 → /fork
当前用 Redis 实现分布式锁，你想试试 PostgreSQL advisory lock，就输入 /fork。新会话完整继承所有上下文，但拥有独立 ID，两个方向可并行推进。
方法三：开始完全无关的新任务 → /new
支付系统已交付，现在要分析另一个项目的 API 延迟问题，就输入 /new api-latency-analysis。旧会话保留在后台，新会话清空上下文，但终端屏幕保留滚动历史。
方法四：上下文和屏幕一起重置 → /clear
既不想带着旧历史，也不愿看到满屏日志干扰视线，就输入 /clear。这会清空所有对话记录+清屏，但 Codex 进程仍在运行，不用重新启动。
预防性处理：分块读取大文件 + 主动交接
第一步：避免一次性塞入超长内容
不要写 codex "分析 $(cat large_file.py)"，改用 head 或 sed 提取关键段落：
codex "分析 $(head -n 300 src/core/processor.java)"
第二步：为长任务设计“接力点”
当 /status 显示 token 使用量超过 180K 时，立即生成 handoff 摘要：
codex --print "将当前状态、已完成步骤、待办事项、验证方式汇总为一段不超过200字的handoff" --max-turns 1
第三步：新开会话并注入摘要
执行 /new 后，把上一步生成的摘要粘贴进去，开头加一句：“按此 handoff 继续执行剩余任务。”
第四步：验证新会话是否承接准确
让 Codex 复述当前任务目标、上一步修改的文件名、以及下一步要运行的命令。若答错，说明 handoff 缺失关键锚点，需补全行号或变量名。
