Codex 变慢或变卡时，最快找到解决办法的方法，是先弄清时间花在了哪里。如果 AI 的回复慢，就检查服务器和设置；如果启动慢，就检查 MCP 服务器和设置文件夹；如果应用界面卡顿，就检查应用版本和会话长度；如果命令执行慢，就检查文件的存放位置和电脑性能。本文根据 OpenAI 的官方文档，以及 OpenAI 工作人员在 Codex 的 GitHub 上给出的回答（2026年10月25日确认），按症状整理了处理方法。

根据症状决定查看哪里

症状 A

AI 的回复慢或停住不动

服务中断或拥堵、推理强度、模型、线程长度 → 第 2 章

症状 B

启动慢，或要等很久才能输入

等待 MCP 服务器启动、设置文件夹、版本过旧 → 第 3 章

症状 C

应用卡顿或无响应

应用版本、长线程、堆积的运行任务、Windows 问题 → 第 4 章

症状 D

执行命令慢

WSL 中文件的存放位置、电脑性能 → 第 5 章

Codex 可以在 ChatGPT 桌面应用（Windows 和 macOS）、CLI（在终端中使用的版本）以及 VS Code 等编辑器的扩展中使用。本文把一组工作往来称为“线程”：在应用中是一个聊天，在 CLI 中是一个会话。无论哪种形式，负责思考的模型都在 OpenAI 的服务器上运行，AI 请求执行的命令则在你的电脑上运行。症状用颜色区分：回复 启动 应用 命令。

1. 先做判断

觉得慢的时候，请看一下屏幕，依次确认以下三点。

  1. 是否在等待批准Codex 可能正在请求你批准执行命令或修改文件，因此停在那里不动。OpenAI 的故障排除指南也把这一点列为看起来卡住时首先要确认的事项。
  2. 它现在正在做什么如果在能够输入之前一直在等待，或者 MCP 服务器准备中的提示一直显示，那就是启动问题；如果“正在思考”或“正在写回复”的提示一直显示，那就是回复问题；如果命令一直在执行中而没有进展，那就是命令问题；如果输入或切换界面本身就很迟钝，那就是应用问题。
  3. 是否所有人都慢请查看 OpenAI 的服务状态页面，确认 Codex 是否有服务中断。如果有服务中断，通常在本地几乎无能为力。

在 CLI 中，/status 可以显示当前使用的模型、已用的 token 数量，以及剩余的上下文（线程记忆中的可用空间）。如果剩余上下文较少，请参阅第 2 章的“不要长时间沿用一个长线程”；如果推理强度设为 High 或更高，请参阅第 2 章的表格。

2. AI 的回复慢时 回复

服务器端的拥堵或服务中断

有些慢并非本地原因造成。在一条反馈“快速模式和标准模式一样慢”的报告下，OpenAI 工作人员回复称“We had a capacity issue last week”（上周出现了容量问题），之后又表示已经缓解（openai/codex #24422，2026年6月）。这说明服务器端容量不足也会导致变慢。关于“模型处于容量上限”的提示，请参阅“Codex 的“Selected model is at capacity”提示的处理方法”。

让推理强度与任务相匹配

在 Codex 中，可以选择模型在回答之前思考的程度。强度越高，思考越深入，消耗的时间和用量也越多。OpenAI 的官方说明如下（OpenAI “Models”）。

强度官方说明适合的工作（参考）
Light（CLI 中为 Low）适合快速、范围明确的工作单处修改、回答问题
Medium速度与深度兼顾日常实现
High 与 Extra High适合步骤或资料较多的困难工作（OpenAI 对这两个档位的说明相同）Extra High 思考时间更长涉及设计的修改、原因不明的错误
Max优先考虑深度而非速度和用量，思考时间更长其他方法都无法解决的难题
Ultra将复杂工作拆分给子代理以加快速度官方未说明对用量的影响可以拆分成多个部分的大型工作

在 CLI 中，使用 /model 与模型一同选择。可以在设置文件（config.toml）中通过 model_reasoning_effort 设置默认值。最低的档位在应用中显示为 Light，在 CLI 和设置文件中显示为 low。

如果总是使用 High 或更高的强度，即使是简单的任务也会等待很久。对于小的修改，把强度降到 Light（CLI 中为 low）或 Medium，回复会更快。OpenAI 的模型选择页面建议，在细微编辑和范围明确的工作中，搭配较轻量的模型 GPT-6 Luna 与 Light（Low）使用（OpenAI “Model selection”）。

快速模式（Fast 与 Ultrafast）

如果想缩短等待时间，可以使用更快的模式，代价是消耗更多用量（OpenAI “Speed”）。

模式适用对象和可使用的人速度用量消耗（使用 ChatGPT 登录时）
Fast支持的模型，包括 GPT-6.1 Sol、GPT-6 Astra、GPT-6 Sol 和 GPT-6 Luna使用 ChatGPT 登录的应用、CLI 和编辑器扩展官方未公布倍率套餐用量为标准的 2.5 倍购买的额度按 2 倍计算
UltrafastGPT-6 Astra 和 GPT-6.1 SolPro（月费 500 美元的档位）以及符合条件的 Enterprise 和 Edu 方案（价格，10月25日确认）使用 GPT-6 Astra 时，生成文字的速度最高可达标准的 8 倍用量为 8 倍额度按 6 倍计算

在 CLI 中，使用 /fast 切换。如果当前使用的模型没有更快的档位，就不会显示 /fast。如果使用 API 密钥登录，则按 API 价格计费，上述倍率不适用。

不要长时间沿用一个长线程

如果在同一个线程中持续处理许多任务，上下文会不断膨胀，回复和界面都会变得沉重。在一条反馈“线程在长时间使用后变慢”的报告下，OpenAI 工作人员建议为每项任务新建一个线程。

OpenAI 工作人员（openai/codex #11984，2026年2月25日）

“We recommend creating a new thread for each task”
（建议为每项任务新建一个线程）

该工作人员还补充说，如果持续使用同一个线程，每次压缩都会稀释上下文，而重新开始更快，也能避免模型被过去的工作分心（openai/codex #11984）。

如果确实想继续使用同一个线程，可以在 CLI 中使用 /compact，对之前的往来内容进行摘要，从而释放上下文（官方说明为“Summarize the visible chat to free tokens”）。/new 则会开始一个新线程（OpenAI “Slash commands”）。

3. 启动慢时（CLI 与 MCP） 启动

等待 MCP 服务器启动

如果你在 Codex 中注册了 MCP 服务器（连接外部工具的一种机制），每次启动时都要等待这些服务器准备就绪。非必需的服务器默认只等待 1 秒，然后就继续进行。设置为 required = true 的服务器则会一直等到启动完成（默认最多等待 10 秒）。如果保留着响应缓慢的服务器，或者已经不再使用的服务器，首次回复就会延迟。OpenAI 的官方设置如下（OpenAI “Model Context Protocol”）。

确认是否设为必需
设为 required = true 的服务器会一直等到启动完成（startup_timeout_sec，默认 10 秒）。如果无法启动，Codex 本身也无法启动。把不需要的必需设置去掉，效果最明显。非必需的服务器最多等待 mcp_optional_startup_grace_ms（默认 1000 毫秒）。
停用不使用的服务器
在 config.toml 中该服务器的部分写入 enabled = false无需删除服务器设置，即可将其停用。
缩短必需服务器的等待上限
降低该服务器的 startup_timeout_sec（默认 10 秒）如果降得太低，启动需要时间的服务器将无法使用。
检查注册情况
在 CLI 中使用 /mcp，或在终端中使用 codex mcp list，查看已启用的服务器
# ~/.codex/config.toml 示例：停用不使用的服务器
[mcp_servers.old-server]
command = "npx"
args = ["-y", "old-mcp-server"]
enabled = false

设置文件夹过大或已损坏

在一条反馈“CLI 启动慢”的报告下，OpenAI 工作人员指出，保存设置和记录的 ~/.codex 文件夹可能过大或已损坏，并建议暂时更改其名称进行测试（openai/codex #9290，2026年1月）。更改名称后，Codex 会以首次使用时的状态启动，因此需要重新登录。过去的线程记录也保存在这个文件夹中，所以只更改名称，不要删除，测试结束后请恢复原名。

# macOS 和 Linux：更改名称
mv ~/.codex ~/.codex-backup
# Windows（PowerShell）：更改名称
Rename-Item $HOME\.codex .codex-backup

恢复时，先把测试期间新生成的 .codex 改成其他名称（例如 .codex-test），再把 .codex-backup 改回 .codex。

确认是否在使用旧版本

一些 CLI 版本包含启动相关的改进。例如，0.152.0 版（2026年9月1日）减少了首次回复前的延迟，0.161.0 版（10月7日）则改为在启动时更早地发现记录数据库的损坏（GitHub 发布页）。使用 codex --version 确认版本，再使用 codex update 检查并安装更新。如果你使用的安装方式不支持 codex update（例如通过包管理工具安装），请使用安装时相同的方式更新。桌面应用中内置的 Codex 版本可能与 CLI 不同，应用需要单独更新（参阅第 4 章）。

4. 应用卡顿或无响应时 应用

更新到最新版本并重启

桌面应用的许多迟滞问题已在版本更新中修复。

Windows

在一条反馈 Windows 上应用无响应或卡顿的报告下（openai/codex #20214），OpenAI 工作人员于2026年8月28日写道，他们已修复其中一个原因。

OpenAI 工作人员（openai/codex #20214，2026年8月28日）

“ChatGPT v26.825.32147 includes a fix for one cause of Windows stuttering and slowdowns during long sessions.”
（ChatGPT v26.825.32147 修复了长时间使用时 Windows 卡顿和变慢的一个原因）

据该工作人员说明，其中一个原因是在沙箱中运行的命令，占用了负责绘制屏幕的 Windows 组件 dwm.exe 的资源并不断累积。他建议更新到 v26.825.32147 或更高版本，然后重启应用。

该工作人员写的是“一个原因”，而截至2026年10月25日，这个问题仍未解决，即使更新之后，仍有用户持续报告因其他原因导致的无响应。Windows 版应用通过 Microsoft Store 分发，因此请在 Store 的“库”中检查更新（OpenAI “ChatGPT desktop app for Windows”）。

macOS

关于 macOS 上 CPU 占用率过高的问题，工作人员写道，已在2026年4月的版本（v26.415.20818）中修复（openai/codex #16231）。另一方面，关于辅助进程堆积导致输入延迟的报告，截至10月仍未解决（#25744）。请将应用更新到最新版本，变卡时重启。

无论在哪个操作系统上，首先更新到最新版本并重启应用都是最先应该做的。

官方的“卡住时”处理步骤

OpenAI 的故障排除指南对卡住时的处理步骤有如下说明（OpenAI “Troubleshooting”）。

线程看起来停住了
除了第 1 章的确认之外，在终端中运行 git status 之类的简单命令 → 用范围小、明确的请求开始一个新线程
应用中的终端卡住了
关闭终端面板，按 Ctrl+` 重新打开，然后运行 pwd 或 git status如果仍然卡住，请等正在运行的线程结束后再重启应用。

整理线程

在一个线程中长时间工作（第 2 章）也会影响界面的卡顿程度。至于线程数量，GitHub 上仍有未解决的报告称，切换线程很慢，线程一多 CPU 就持续占用（#11011 等）。官方并未说明归档能使应用变轻，但把已经用完的线程归档（CLI 中使用 /archive，即从列表中移除但不删除记录；或使用应用中的归档功能），可以防止列表无限膨胀。

如果你在使用定时任务，官方故障排除指南中有相关步骤。频繁运行的定时任务会不断累积 worktree（工作文件夹的副本），因此应归档已不需要的运行记录，并且不要固定保留没有必要保留的运行记录（OpenAI “Troubleshooting”）。

5. 命令执行慢时（WSL 与文件存放位置） 命令

AI 请求执行的构建、测试和搜索命令都在你的电脑上运行。如果这些命令执行慢，应检查的是文件的存放位置和电脑性能，而不是模型或设置。

使用 WSL 时，把文件放在 Linux 一侧

如果你在 Windows 中的 Linux（WSL）里运行 Codex，工作文件夹的位置会对速度产生很大影响。OpenAI 的说明是，在 /mnt/c/... 这类 Windows 驱动器路径下工作可能会变慢，并建议把代码仓库放在 Linux 的主文件夹中（例如 ~/code/my-app）。如果大型代码仓库运行缓慢，OpenAI 还建议增加分配给 WSL 的内存和 CPU，并更新 WSL（OpenAI “WSL”）。

# %UserProfile%\.wslconfig 示例：分配给 WSL 的内存和 CPU
[wsl2]
memory=8GB
processors=4
# 更新 WSL，然后将其关闭以使设置生效（在 PowerShell 中）
wsl --update
wsl --shutdown

关于 .wslconfig 的写法，请参阅 Microsoft “Advanced settings configuration in WSL”。wsl --shutdown 会停止所有正在运行的 WSL，因此请先关闭正在处理的内容再执行。数值请根据你电脑的内存和 CPU 数量设置。

需要注意的是，在 Windows 应用中使用“保持在 Windows 上”的代理时，推荐的存放方式正好相反。

代理在 WSL 中运行时

放在 Linux 一侧（如 ~/code）

在 /mnt/c 下工作可能会变慢（OpenAI “WSL”）。

Windows 应用中代理保持在 Windows 上运行时

放在 Windows 一侧的文件夹中

代理在 Windows 一侧运行，因此 /mnt/c 的慢速不会影响它。这比直接在应用中打开 WSL 内的文件夹更可靠（OpenAI “ChatGPT desktop app for Windows”）。只有在用 WSL 一侧的工具处理同一个代码仓库时，才会经过 /mnt/<驱动器>/...，这些操作可能会变慢。

出处：OpenAI “ChatGPT desktop app for Windows”。Windows 应用默认使用“保持在 Windows 上”的代理，切换到 WSL 时需要重启应用。在一条反馈 WSL 代理极其缓慢的报告下（#25715），工作人员表示预计能缓解问题的修复已于2026年6月5日合并，但截至10月25日，该问题仍未解决。

电脑性能起作用的地方

命令执行所需的时间取决于电脑的 CPU、内存和存储（尤其是 HDD 还是 SSD）。应用界面的流畅程度也会受电脑影响。不过，AI 思考并写出回复所花的时间，不会因为更换电脑而改变。关于哪些方面取决于电脑，以及如何测量时间的分布，请参阅“运行 Claude Code 与 Codex 所需的电脑配置”。

6. 问题仍未解决时向 OpenAI 反馈

如果按上述方法仍无法解决，可以向 OpenAI 反馈。OpenAI 的工作人员可以查看记录，寻找原因。

  • 从 CLI 发送：在 CLI 中使用 /feedback，即可将记录和诊断信息发送给 Codex 团队（按提示操作，并选择要包含的内容）
  • 在 GitHub 上搜索：在 openai/codex 的 issues 中查找相同症状的报告以及工作人员的回复。反馈时请写明版本号和操作系统
  • 获取详细的 CLI 日志：默认不会生成纯文本日志。如果指定日志位置启动 CLI，例如 RUST_LOG=debug codex -c log_dir=./.codex-log（在 Windows 的 PowerShell 中为 $env:RUST_LOG="debug"; codex -c log_dir=./.codex-log），就会生成 codex-tui.log（OpenAI “Environment variables”）

日志中可能包含工作内容和文件路径。在公开场合张贴之前，请删除密钥等敏感信息和个人信息。

总结

  • 先确认是否在等待批准、当前正在做什么，以及是否有服务中断
  • 如果回复慢，请按任务降低推理强度、切换到更轻量的模型，或使用快速模式（用量消耗会增加）
  • 为每项任务新建一个线程（OpenAI 工作人员建议这样做），如需继续则使用 /compact
  • 如果启动慢，请检查必需的 MCP 服务器，用 enabled = false 停用不使用的服务器，并更新 CLI。如果仍无效，可暂时更改 ~/.codex 的名称进行测试
  • 如果应用卡顿，请先更新到最新版本并重启，然后归档已不需要的定时任务运行记录
  • 使用 WSL 时，把文件放在 Linux 一侧（如果在 Windows 上原生运行，则放在 Windows 一侧）
  • 如果问题仍未解决，请使用 /feedback 发送记录，并在 GitHub issues 中搜索相同症状

常见问题

Q. Codex 比 Claude Code 慢吗？

无法一概而论。速度会因推理强度、模型、任务类型、应用缺陷以及本地命令的耗时而有很大差异。对两者在相同条件下进行比较的测量很少，而且模型本身也不同，因此仅凭单次测量的数字做判断是有风险的。关于两者中哪些部分取决于电脑、哪些不取决于电脑，请参阅“运行 Claude Code 与 Codex 所需的电脑配置”，其中有并列说明。

Q. 使用快速模式一定会更快吗？

快速模式会提高模型生成文字的速度，但不会改变命令执行的时间，也不会改变 MCP 服务器的启动等待时间。在服务器繁忙的时段，即使使用快速模式，仍可能感觉很慢（第 2 章）。套餐用量也会更快耗尽，因此最好只在需要尽快完成的工作中使用。

Q. VS Code 扩展无响应或卡顿怎么办？

请将扩展和 VS Code 更新到最新版本，然后重启 VS Code。官方文档中没有针对扩展卡顿的具体步骤，但线程的长度（第 2 章）同样会影响扩展。如果在 Windows 上扩展无响应，OpenAI 的文档建议先安装 Microsoft C++ 生成工具和 Visual C++ 可再发行组件包，然后完全重启 VS Code（OpenAI “Windows sandbox”）。