最近一周我的 Codex 几乎到了没法用的程度输入两三个字终端要等半分钟才回显问一个简单的函数签名转圈转到人上火最夸张的一次连续三条请求全部超时我甚至怀疑电脑是不是被人塞了个挖矿脚本。把任务管理器翻了一遍CPU 和内存都没爆网络延迟也正常最后把 Codex 的日志扒出来一条条看才算把问题定位清楚。说起来也讽刺这工具刚装上的时候还是“嗖嗖嗖”出代码的状态越用越卡卡到“要命”往往不是某一处代码写错了而是运行链路里好几个环节在悄悄恶化。这篇文章我就按自己这几天的真实排查顺序把 Codex 卡顿的核心原因和能直接抄作业的解决方法整理出来。只要你的 Codex 也是从 GitHub 上下载后日常使用的增强版编码助手照着这套思路走基本都能恢复到能用的状态。1. Codex到底卡在哪一层先拆开运行链路再动手很多人一遇到卡顿第一反应是“重装”“重启”“换电脑”其实这是把问题想大了。Codex 不是单个进程它是一整条链路终端或编辑器里的交互界面加上本地跑的代理/辅助进程再连到远端的模型推理服务。三环里任何一环出问题表现都是“卡”但修法完全不一样。1.1 Codex 启动之后的进程关系先从实际部署说起。以我自己的安装方式为例我是从 GitHub 仓库拉取源码或 release 包在本地完成依赖安装后运行。启动后能看到几个进程一个主程序进程负责解析我的输入、维护会话和调用模型一个会话管理/缓存相关的子进程负责把对话历史写入本地文件可能还有一个和编辑插件联动的辅助进程比如 VSCode 扩展的 server 端。判断卡顿在哪一层最简单的办法是看“卡在哪个阶段”。如果是打字就卡、界面冻结问题大概率在客户端渲染或本地资源占用如果是回车之后长时间没有反应那一刻 CPU 突然升高问题可能在本地处理如果本地进程很平静纯等网络返回那就是远端服务或网络链路的问题。1.2 三分钟定位瓶颈层的实操自测我通常用一套非常原始但有效的操作来定位启动 Codex 后打开系统的进程监视器记下主进程和子进程的 CPU、内存基线发送一个最简单的请求比如“你好”观察各进程的实时占用再发一个稍微复杂的请求比如“给我写一个带异常处理的 HTTP 客户端”继续观察。如果简单请求都慢、且 CPU 一直很高那问题在本地如果简单请求很快、复杂请求才慢那是模型推理或请求体大小的影响重点往上下文和配置上想如果不管什么请求都等着而且本地进程几乎没动静那问题多半在网络或远端服务侧。这套自测帮我排除了电脑自身的问题因为 Codex 的主进程只占 25% 内存和少量 CPU明显不是硬件瓶颈。那问题只能落在链路的后半段。2. 缓存、会话历史与日志膨胀三个最隐蔽的“卡顿制造机”真正让我 Codex 从“慢”变成“慢得要命”的是本地这堆我看不见的文件。和大家想的不一样Codex 这种工具不会每次请求都从零开始它会把历史会话、缓存摘要、日志全部写到本地目录里。平时不觉得连续用上几周之后这些文件会像滚雪球一样越滚越大最后反过来拖垮整个工具。2.1 长会话为什么会让请求体指数级膨胀我遇到的最典型的场景是在同一个会话里连续讨论了三个多小时。从改功能到修 bug再到重构代码整个对话历史积累了几百轮。Codex 在每次发起新请求时需要把之前的会话上下文一起带上作为模型的输入。上下文越长请求体就越大模型端处理的时间也越长而且这个增长不是线性的——上下文大到一定程度后响应时间会显著恶化。你可以这样理解你让一个助手帮你干活但每次都要把你们从第一天认识到现在的所有聊天记录重新读一遍他才能理解你现在的需求。读得越多反应自然越慢。实话说长会话用久了Codex 的后续请求延迟从“几秒”涨到“几十秒”甚至出现超时这几乎是必然的。2.2 怎么找到并清理 Codex 的缓存和日志目录Codex 的本地数据目录在 macOS 和 Linux 上通常位于用户目录下的隐藏文件夹里比如 ~/.codex、~/Library/Application Support/Codex或者沿用 Codex CLI 风格的 ~/.codex。自己不确定的话两个办法最快在 Codex 的配置或设置界面里看“数据目录/缓存目录”的路径用lsof -c codex之类的命令查看进程打开了哪些文件路径就一目了然。拿到路径后先不要直接删。把目录下的结构列出来一般会有history/、cache/、logs/几类。我当时的处理办法是# 先看各子目录占了多少空间 du -sh ~/.codex/* # 备份历史记录以防万一 cp -r ~/.codex ~/.codex_backup # 清理缓存和旧日志保留最近的 rm -rf ~/.codex/cache/* rm -f ~/.codex/logs/*.log.old注意会话历史不建议全清否则你之前和 Codex 同步的上下文会全部丢失。我试过最靠谱的做法是把当前不用的长时间会话归档只保留最近两三个活跃会话。这样下一次请求携带的上下文体积能降一个数量级。2.3 清理前后的实测数据对比清理完缓存和归档历史之后我特意用了同一段代码改动请求做对比测试项目清理前清理后缓存目录占用1.2GB180MB单次请求首字延迟25~40秒4~6秒完整响应时间60~90秒10~15秒连续三次请求是否超时偶尔超时无超时这个结果非常直观。别小看本地文件的清理它最直接地解决了“越用越慢”的积累问题。这也是我这次排查里投入产出比最高的一步如果你现在卡得厉害先做这一步大概率能恢复一半以上的流畅度。3. 版本配置和更新姿势从 GitHub 拿到的包为什么越修越卡缓存清完了Codex 还是偶尔抽风。我又把注意力转移到版本和配置上。这一块是很多人包括我容易栽跟头的地方——倒不是不会装而是太喜欢“追新”以及改配置时只改参数不懂原理。3.1 从 GitHub 更新 release 包的常见错误Codex 在 GitHub 上发布新版本时一般提供源码包和预编译的二进制包。我这次踩的坑是直接下载最新的 zip 压缩包解压后整个覆盖到原来的安装目录。看起来没问题实际上旧版本的一些残留配置、插件或者动态库文件还躺在原来目录里新版本启动时会加载到这些不兼容的残留物轻则功能异常重则反复重试、卡顿。官方 README 里其实写了好几种安装方式包管理器比如 npm、brew、源码编译、release 二进制。如果你用的是源码编译升级时直接git pull之后重新安装依赖一般比解压覆盖要干净但要特别注意依赖版本是否更新。我这次就发现本地某个依赖库停留在旧版本Codex 新版本每次启动都会尝试下载新依赖每次启动都“卡”在老半天。建议这样操作# 进入 Codex 源码目录拉取最新代码 git pull origin main # 如果项目有依赖锁文件先清掉旧的 node_modules 或虚拟环境再重装 rm -rf node_modules npm install如果你用的是 release 二进制先把旧的目录完全删除再解压新的进去不要直接在原目录上覆盖。3.2 关键配置项的逐项调优Codex 一般会有一个配置文件常见的是config.toml、config.json或者.env格式。里面有几个参数直接决定卡顿表现很多人只修改模型名称其他的一概不动。我列一下最容易影响体验的几个项以及我实测下来比较合理的范围配置项作用我踩过的坑建议值timeout单次请求的最大等待时间设成 300 秒一旦网络抖动界面像死了一样30~60 秒max_retries失败后自动重试次数默认 3遇到限流时三次重试全部堵在队列里1最多 2concurrency同时发出的请求数设成 5直接触发服务端限流1最多 2model实际使用的模型规格为了效果一直用最大模型性能差时卡到爆按场景切换日常用响应更快的型号streaming是否流式返回关闭时必须要等全部结果生成完才显示保持开启很多人的概念是“超时时间设大一点总比超时强”这是错的。超时设太长会让每次失败都变成几分钟的干等而且后面排队的新请求全部被卡住。把超时调到 30~60 秒配合重试次数调低反而能让链路更快暴露问题而不是无限期拖下去。3.3 改完配置之后为什么还是没效果配置改完之后如果只是把文件保存很多 Codex 变体并不会自动重新加载。我那次就犯了这个错改了concurrency和timeout然后继续在同一个老进程里测试结果发现一点变化都没有差点以为配置没生效。正确的做法是完整退出 Codex 相关进程之后重新启动。如果还不行再看看是不是存在多个配置文件比如全局配置和项目级配置后者会覆盖前者。你可以通过codex doctor或类似的诊断命令查看当前实际加载的配置来自哪个文件确保你改的是被读取的那一个。4. 隐形排队与重试风暴为什么卡顿像“抽风”一样一阵一阵的如果你已经清过缓存、合理调过配置但还是出现“有时好有时坏”的抽风卡顿那问题很可能不在本地而在请求队列和远端限流的交互上。这种卡顿最迷惑人因为表面上看进程正常、网络正常但请求就是一个接一个超时。4.1 我记录到的一次抽风全过程那天我在终端里连续发了 6 条请求中间间隔不到一分钟。第一条正常第二条稍微慢了一点第三条开始转圈第四条直接超时第五条却秒回。这种反复非常典型。打开 Codex 的 verbose 日志我看到了非常关键的信息在我发完第二条请求后日志里就出现了“rate limit exceeded”之类的提示随后是连续的重试记录第三条请求其实是在重试之前的那一条真正的新请求反而排到了更后面。这就是典型的请求排队加重试风暴前一个请求超时后自动触发重试重试又占用了连接资源新请求只能等待。4.2 为什么并发调高反而更慢从直觉上讲并发调到 5一次能处理 5 个任务不是更快吗在 Codex 这种需要调用远端模型服务的工具里并发过高反而会引发两个问题一是远端服务有请求频率限制。你把并发提到 5 个同一时间发出 5 条请求很容易直接触发限流服务端返回“请求过多”的报错客户端再进入重试循环。二是本地任务队列会被失败任务填满。真正需要处理的新任务排不进去表现出来就是“卡住不动”。所以我把concurrency从 3 降到 1 之后现象立刻改变。一次只发一个请求最多两个反而每个请求都能顺利完成整体吞吐没有降低体感速度还提升了。4.3 看日志定位“排队点”的命令技巧Codex 如果支持 verbose 或 debug 模式强烈建议打开一次观察完整请求链路。常用的打开方式是启动参数加--verbose或者在配置里把log_level改成debug。开启后重点看三类内容请求进入时间确认新请求是否真的发出去了还是卡在本地队列等待服务和重试标记一旦出现retrying、rate limit、backoff这类关键词说明进入了重试循环服务端返回耗时可以从日志里看到远端响应耗时判断是远端慢还是本地慢。我当时一打开 verbose 模式两分钟就看到“罪魁祸首”每一条超时请求后面都跟着三条自动重试而重试失败后还有指数退避等待两个重试周期就把时间轴完全占满了。把max_retries改成 1再配合超时时间下调抽风卡顿立刻消失。5. 慢到快崩溃时的实战排查清单照着这个顺序做一小时恢复流畅到了这一步我的 Codex 已经恢复到了可用状态。为了让同样被折磨的人少走弯路我把这次完整的排查顺序整理成了一张可执行的清单。不是从原理出发而是从“最快见效”的顺序出发。5.1 从最可能见效的操作开始逐级排查我建议你按这五步来每一步都观察是否改善再决定是否进入下一步重启 Codex并且完全退出相关子进程后重新启动。这能解决缓存锁死和临时占用问题。清理缓存和日志目录归档超长会话。操作见第 2 节这一步能解决 80% 的“越用越慢”。检查版本更新方式。源码安装的就重新git pull并重装依赖release 安装的就整目录删除重装。修改timeout、concurrency、max_retries改完必须完全重启进程。开启 verbose 日志观察是否有排队和重试风暴再回头检查并发参数。这五步每做完一步就实际发两条请求试试。不要着急一次性全改否则你根本不知道是哪个改动起了作用。5.2 日常使用中我保留的三个防卡习惯排查完这次之后我不再像以前那样“用到卡了再处理”而是养成了几个稳定防卡的习惯每个大任务开一个新会话不在同一个会话里无穷尽地堆积历史。功能开发、调试、重构分开每次请求的上下文体积能控制在合理范围内。不在高峰期同时开多个终端窗口向 Codex 发请求。多个窗口同时请求相当于隐形提高了并发触发限流的概率剧增。定期看一眼日志大小和缓存占用每周至少清理一次 logs 目录。日志文件滚得很大之后磁盘 IO 都会受影响这种慢性卡顿非常难察觉。5.3 最后再分享一个小技巧如果你手头在做的事情特别复杂容易被超时打断我建议把大任务拆成几个小任务分次发送。这不是绕弯子而是 Codex 这类工具在面对超长上下文和超长生成任务时响应性能本来就会急剧退化。一次只让它解决一个函数、一个模块比一次让它“重构整个项目”要稳定得多。我在拆分任务之后不仅卡顿少了生成结果的可用性也高了这算是顺手得到的额外好处。说到底工具卡顿这件事百分之八十是使用习惯和本地数据积累造成的真正硬件或代码本身的问题反而少见。按上面的步骤排查下来我的 Codex 已经从“卡到心态崩”恢复到了“能安心写代码”希望你也能用它恢复流畅。如果后续再遇到奇怪卡顿优先打开 verbose 日志让数据说话比盲猜靠谱太多了。