如果 Codex Desktop 在 Windows 或 WSL 里明显变慢，而同一个小任务在 Codex CLI 或 IDE 扩展里很快完成，先把正在进行的仓库工作放到更快的入口里，再单独诊断桌面应用路径。不要先改一堆设置，也不要把一次慢响应直接归因给模型、网络或 WSL；先做一组可复现的同一提示对比。
| 你现在看到的情况 | 先用哪个入口 | 原因 |
|---|---|---|
| CLI 或 IDE 很快，桌面应用明显慢 | CLI 或 IDE | 当前代码修改不应该卡在桌面应用路径排查上。 |
| 任务需要 worktree、长线程、Git Review、浏览器任务、Artifacts 或 Computer Use | 桌面应用 | 这些是桌面应用真正拥有优势的工作流，即使普通改代码可以转到 CLI。 |
| 同一提示在 CLI、IDE 和桌面应用都慢 | 先查模型、账号、服务状态、仓库复杂度和提示范围 | 慢点还没有被隔离到桌面应用。 |
| 桌面应用在可比条件下仍然慢很多 | 走报告路径 | 需要版本、Windows/WSL 模式、项目路径、计时、Fast mode 状态和脱敏日志。 |
Fast mode 可以让受支持模型的响应更快，但它不是本地 Windows/WSL 开销已经消失的证据。真正有用的记录包括桌面应用版本、内置 agent 版本、`codex --version`、Windows 版本、WSL 发行版和模式、项目路径、同一提示计时、Fast mode 开关状态、日志位置和你已经排除过的变量。
先跑五分钟的同一提示测试
有价值的测试故意很朴素：同一个仓库、同一个很小的提示、相近的模型和审批设置，然后比较不同入口。不要在第一轮测试前重装应用、清缓存、改 WSL 模式、移动仓库或打开 Fast mode。你需要先有一个基线，否则后续任何变化都很难解释。
可以用一个足够小但真实的任务，例如“检查这个文件并建议最小安全修复”。测试时记录两段时间：第一次有用响应出现的时间，以及最后可用答案完成的时间。桌面应用、CLI、IDE 扩展和可选的云端都使用同一段提示；如果某个入口需要额外权限或额外确认，把这个差异写下来，而不是把它混进响应时间。
还要同时记录环境变量：桌面应用版本、可见的内置 agent 版本、`codex --version`、IDE 扩展版本、Windows build、WSL 发行版和版本、项目路径是在 Windows 文件系统、`/mnt/
如果 CLI 和 IDE 也慢，桌面应用还没有被隔离出来。此时优先检查账号额度、模型服务、仓库上下文过大、测试命令过慢、网络问题或提示要求 Codex 一次性读太多文件。额度、包含用量和 Fast mode 的信用消耗可以参考 OpenAI Codex 用量限制说明；如果担心的是 API key 下 CLI 的真实花费，就用 Codex CLI token 成本估算，不要从“体感慢”倒推成本。
把 Windows 与 WSL 边界拆开
OpenAI 的 Codex Windows app 文档 是 Windows 安装与执行路径的事实来源；本轮核验时间是 2026-07-08。Windows 应用可以走原生 Windows agent，也可以切到 WSL2 agent 模式。两条路径看到的文件系统、工具链、配置目录和沙箱行为都可能不同，把它们当成同一个入口会掩盖真正的瓶颈。
| 设置事实 | 为什么会影响慢感 | 更稳的检查方式 |
|---|---|---|
| 原生 Windows agent | 应用从 Windows 侧运行，路径、Git 和沙箱都偏 Windows 语义 | 选一个 Windows agent 能清楚访问的项目路径。 |
| WSL2 agent 模式 | agent 环境切到 WSL，工具链和 home 目录随之改变 | 在 Settings 里明确切换并重启后再比较。 |
| 当前官方文档不支持 WSL1 | 旧教程可能给出错误预期 | 先确认 WSL2，再讨论 WSL 行为。 |
| Windows 路径、`/mnt` 路径和 `\wsl$` | Git 识别、文件监听和路径转换成本可能不同 | 避免用会隐藏 Git 或制造路径翻译的路径做基准。 |
| `CODEX_HOME` 分裂 | Windows app 和 WSL CLI 默认可能读不同配置 | 只在理解影响后同步或设置 `CODEX_HOME`。 |
关键不是“WSL 一定慢”或“原生 Windows 一定快”。关键是 Windows app、WSL agent、WSL 里的 CLI、Windows 里的 IDE 扩展可能是不同执行路径。一次只改一个变量：先比较 app native 与 CLI，再比较 WSL agent 与 WSL CLI，再比较同一仓库复制到干净路径后的结果。这样得到的差异才可以用于决策。
按工作所有者选择入口
Codex CLI 和桌面应用不是简单替代关系。OpenAI 的 CLI features 文档 重点覆盖终端 TUI、resume、`codex exec`、review、脚本化、shell completions、web search 和 prompt editing；OpenAI 的 app features 文档 重点覆盖 worktrees、automations、Git review、集成终端、内置浏览器、Computer Use、artifacts、IDE sync 和线程监督。
| 入口 | 桌面应用慢时最适合先承担的工作 | 不要把它当成 |
|---|---|---|
| Codex CLI | 终端里的仓库编辑、脚本、SSH、容器、快速本地对比 | 桌面应用已经没价值的证明 |
| IDE 扩展 | 编辑器旁边的小改动、快速 patch review、当前本地开发 | 长线程和应用监督的替代品 |
| 桌面应用 Local | 线程管理、artifacts、Git review、浏览器、Computer Use、UI 工作流 | 每一次仓库编辑的唯一入口 |
| 桌面应用 Worktree | 并行隔离改动和可审查分支 | 修复本地慢路径的手段 |
| Cloud/Web | 不依赖本机状态的离线或长任务 | 调试 Windows 文件系统开销的工具 |
| Computer Use | 需要视觉控制浏览器或 GUI 的任务 | 普通终端改代码的加速器 |
| 报告路径 | 同一提示证明桌面应用单独慢很多 | 粘贴私密日志或猜测根因的地方 |
如果任务是“现在就在这个 WSL 仓库改文件”，而 CLI 或 IDE 已经被证明更快，就先把活放过去。桌面应用仍然适合需要可视化审查、跨线程监督、长任务、浏览器操作和 Computer Use 的工作。GUI 自动化的权限和安全边界可以看 Codex Computer Use 指南；远程监督与本机执行的边界可以看 Codex 移动端指南。
把 Fast mode 当成速度杠杆，不当成诊断结论
OpenAI 的 Codex Speed 文档 把 Fast mode 定义为在更高信用消耗下提升受支持模型速度的选项。它能帮助模型响应速度成为瓶颈的场景，但不能证明桌面应用 UI、Windows/WSL 路径转换、文件监听、扩展桥接、日志写入或本地权限开销已经不存在。
| 测试结果 | Fast mode 能说明什么 | Fast mode 不能说明什么 |
|---|---|---|
| 桌面、CLI、IDE 都明显变快 | 模型响应时间可能参与了瓶颈 | 桌面应用本地路径是否健康 |
| CLI 变快但桌面仍慢 | 模型速度改善，桌面路径仍需排查 | 多花信用就能修好本地开销 |
| 桌面应用在首个有用响应前就慢，CLI 很快 | 本地 surface 开销可疑 | 精确根因是什么 |
| 慢任务包含巨大上下文或长测试 | 任务复杂度可能主导耗时 | Windows 或 WSL 一定有问题 |
最贵的误区是把 Fast mode 当作诊断捷径。正确顺序是先跑基线，再打开 Fast mode 作为第二轮变量。如果开关前后都有计时，你就能判断“模型响应”是否是慢感的一部分；如果没有基线，就只剩体感和信用消耗。
升级前先准备报告包
OpenAI 的 Codex troubleshooting 文档 提醒，app 和 CLI 使用同一 underlying agent 与配置，但版本、实验功能和入口行为仍可能不同。因此有用的报告不是“它很慢”，而是一份能复现差异的最小证据包。
| 字段 | 应包含 | 应脱敏 |
|---|---|---|
| 版本 | 桌面应用版本、内置 agent 版本、`codex --version`、IDE 扩展版本 | 账号标识、私有 workspace 名 |
| 环境 | Windows build、WSL 发行版与模式、项目路径类型、仓库规模信号 | 客户名称、不必要的完整私有路径 |
| 提示 | 能复现延迟的最小提示 | secrets、业务代码、私有 URL |
| 计时 | 同一提示下桌面、CLI、IDE、可选云端的计时 | 与比较无关的聊天内容 |
| Fast mode | 开关状态以及是否改变结果 | 信用余额截图，除非支持明确要求 |
| 日志和 session | app logs、session 引用、终端输出引用 | token、API key、密码、客户数据 |
强报告往往很无聊：同一仓库、同一提示，Windows/WSL 桌面应用 70 秒，CLI 8 秒，附上版本和路径。弱报告会从一次慢会话跳到“Codex 坏了”，中间没有隔离入口，也没有排除模型、网络、仓库复杂度或权限确认。
只做可回滚的排查动作
第一轮基准之后，每次只改一个变量，并记录改动前后的计时。能回滚的检查比“清空一切”的建议更有价值，因为它既保护数据，也保留证据。
| 检查 | 为什么可能有用 | 安全做法 |
|---|---|---|
| 重启桌面应用 | 清掉临时 UI 或 agent 状态 | 记录前后计时。 |
| 确认 Windows native 与 WSL agent 模式 | agent 路径改变文件系统和工具可见性 | 明确切换、重启、再比较。 |
| 把仓库复制到更干净的路径 | 路径翻译或 Git 可见性可能影响 app | 用副本或一次性分支测试。 |
| 比较小仓库和真实仓库 | 区分 surface 开销与仓库复杂度 | 不要只凭 toy repo 下结论。 |
| 分别检查 CLI 与 app 版本 | 版本漂移会解释行为差异 | 报告前同时记录。 |
| 重命名而不是删除状态目录 | 保留回滚能力 | 避免把证据直接删掉。 |
不要直接执行论坛里复制来的大范围清理命令，除非你知道它删除什么、怎么恢复、会不会影响登录、配置、技能、插件或历史 session。一次能解释计时差异的小改动，比一次无法复盘的大重置更有价值。
常见问题
Codex CLI 在 Windows 上一定比桌面应用快吗？
不一定。CLI 在终端原生仓库工作里经常更直接，尤其当慢点来自桌面应用、WSL bridge、路径转换或 UI 开销时。但它不是所有任务的最好入口；同一仓库和同一提示的计时才是当前机器上的证据。
如果 CLI 更快，还要保留桌面应用吗？
要保留。当前代码编辑可以转到 CLI 或 IDE，但桌面应用仍适合 worktrees、长线程、Git review、浏览器任务、Computer Use、artifacts 和跨项目监督。不要把速度比较写成产品排名。
Fast mode 会修复 Codex app 慢吗？
Fast mode 可以加快受支持模型响应，并带来更高信用消耗。它不能证明 Windows、WSL、文件系统、桌面 UI 或本地 agent 开销已经修复。先基准，再决定是否打开。
WSL 最需要记录哪几个细节？
记录 app 使用的是 Windows-native agent 还是 WSL2 agent，项目具体放在哪里，CLI 和 app 分别读取哪个配置 home，以及是否设置过 `CODEX_HOME`。这些细节足以让同一提示在不同入口表现不同。
应该清理 Codex 缓存吗？
不要作为第一步。先重启、基准、记录版本，再尝试可回滚的路径和模式变化。如果必须测试状态清理，先重命名或备份目标目录，这样还能恢复并解释改动。
有用的慢速报告应该包含什么？
包含桌面应用版本、内置 agent 版本、`codex --version`、Windows build、WSL 发行版与模式、项目路径、同一提示在桌面应用和 CLI 或 IDE 下的计时、Fast mode 状态、脱敏日志和 session 引用。不要包含 token、API key、客户数据和还没有隔离出来的根因猜测。