按这个顺序诊断
- 刚装完就报 "codex is not recognized" 或 "command not found"？是安装路径没进 PATH——Windows 上还要装 Git for Windows 并把 C:\Program Files\Git\bin 加进 PATH，因为 Codex 启动时要调用 sh。
- 卡在 "What should we work on?" 或干脆起不来？先升级到 0.162.1 或更新——这个版本修了后台服务器功能配置不一致导致的启动失败——再重置 .codex 目录里的缓存状态。
- 登录死循环、"login not working"？关掉 Codex，删掉 .codex 目录里缓存的 auth.json，重新启动后跑 codex login 重新登录 ChatGPT。
- "stream disconnected before completion"？先看 status.openai.com，断开 VPN 或代理，再用 /model 切到别的模型再切回来——录屏里几秒钟就救活了一个假死会话。
- 在 VS Code 或 Cursor 里坏掉的？插件驱动的还是同一个 CLI——关掉终端重开，模型中途卡住就用 /model 选择器换一个。
How To Fix Codex Stuck On Loading
频道：GUMY Art1:25
OpenAI Codex docs — install, auth & troubleshooting
文档：developers.openai.com/codex
截图来自两段干净录屏：上面的 Windows 卡加载修复（GUMY Art），以及 VS Code 里的流断开修复（w_ntLum92GY，作者 Shivesh）。另有四支视频只作了事实来源——hUndefined 的 "sh" 修复（ey8XJeloUWY）、ZEROBRENE 的升级后配置重置（FzR7ZoET0Qg）、PurpleCircuit 的加载与状态检查（Fk70XxkTHfg、YEMPT7eBka0）——因带人脸摄像头或烧录字幕而未取帧。每一步都深链到来源视频的精确秒数。
视频截图版权归原作者所有，此处仅作为分步文档嵌入，并附署名与时间戳深链。
修复步骤
安装与 PATH —— "不是内部命令"阶段
- 1
先看一次正常启动长什么样
在 VS Code 里打开项目，再打开集成终端输入 codex。正常启动会打印 OpenAI Codex 横幅，带模型行和项目目录，就像录屏里那样。如果 Windows 回你 "codex is not recognized"、macOS 说 "command not found"，直接往下跳：安装没进 PATH，而不是装坏了。
在 VS Code 终端的 bash 提示符下输入 codex 命令在 0:28 观看 - 2
修 Windows 的 "sh 不是内部或外部命令"
Codex 启动时会调用 sh，而 Windows 上的 sh 打包在 Git for Windows 里——去 git-scm.com/downloads 用默认选项装好。然后按 Windows 键输入 environment，打开"编辑系统环境变量"，点环境变量，双击 Path，新建条目 C:\Program Files\Git\bin 并一路确定。把命令提示符完全关掉再重开——PATH 改动只对新终端生效——codex 就能启动了。
启动失败与卡加载 —— 0.162.1 阶段
- 3
认出卡加载的状态
桌面应用停在 "What should we work on?" 再也不动——输入框一直是灰的，任务交不上去，尽管套餐信息还好端端显示在角落。这就是录屏里的卡死状态：根源在 .codex 目录的缓存状态，不在 OpenAI 服务器，所以光重装应用永远修不好。
ChatGPT Codex 应用冻在 What should we work on? 首页在 0:00 观看 - 4
动手前先升到 0.162.1
stable 0.162.1（2026 年 10 月 9 日）"修复了后台服务器功能配置与 CLI 默认值不一致导致的启动失败"——兼容性检查现在只对显式的命令行功能覆盖生效——顺带修了多行异步提问的 TUI 崩溃。跑一下 codex --version；如果看到录屏里 0.114.0 -> 0.116.0 那样的 "Update available!" 横幅，用 curl -fsSL https://chatgpt.com/codex/install.sh | sh（或 npm install -g @openai/codex）重装后再试。
登录与凭据 —— 重置缓存凭据
- 5
全部关掉，再打开此电脑
退出 Codex 并确认它没在后台运行——挂了插件的话 VS Code 也一并关掉。在文件资源管理器里走到 此电脑 → 本地磁盘 (C:) → Users，就像截图那样。macOS 上同一个目录藏在 ~/.codex（访达：前往 → 前往文件夹）。
文件资源管理器停在本地磁盘 (C:)，Users 文件夹可见在 0:26 观看 - 6
进入你的 .codex 目录
在 Users 里打开你的账户文件夹（录屏里是 ryanc），再进 .codex。这里是 Codex 的家：auth.json 存缓存的 ChatGPT 凭据，config.toml 存配置，sessions 存会话记录，sqlite 文件是日志和历史。Codex 启动即卡死，多半就是这些状态文件之一——通常是 auth.json——出的问题。
.codex 目录内部：auth.json、config.toml、sessions 与 sqlite 日志在 0:36 观看 - 7
删掉 auth.json 重置登录
点选 auth.json——状态栏应显示"已选 1 项"——然后删除。"codex login not working" 绕来绕去就是凭据文件的问题：一个被截断或刷新到一半的 auth.json 会让应用启动即卡死，或把你弹回登录页。删掉它是安全的，Codex 只会让你重新登录。
.codex 目录里已选中 auth.json，随时可删在 0:40 观看 - 8
重启并重新登录 ChatGPT
列表从 37 项变成 36 项——auth.json 没了，config.toml 和 sessions 都还在。再启动 Codex，选择 Sign in with ChatGPT，然后在终端跑 codex login status；应显示 "Logged in using ChatGPT"。应用还卡着就重启一次电脑——录屏作者在 Windows 上就需要这一步。
删除 auth.json 后只剩 36 项的 .codex 列表在 0:46 观看
网络报错 —— "stream disconnected before completion"
- 9
正确读懂流断开报错
请求在流式中途死掉时，Codex 会打印 "Falling back from WebSockets to HTTPS transport. stream disconnected before completion. An error occurred while processing your request" 并附上请求 ID——截图里编辑器和 TUI 同时出现了这段话。它通常是瞬时的：上 status.openai.com 查故障，断开可能弄断流的 VPN 或代理，然后直接重试。
贴给 Codex 修的 stream disconnected before completion 报错在 3:00 观看
VS Code 与 Cursor —— /model 切换
- 10
用 /model 切换模型
重试还不行，就打开 Codex TUI 的 /model 选择器——录屏里列着 gpt-5.4、gpt-5.4-mini、gpt-5.3-codex、gpt-5.2-codex 和 gpt-5.1 系列。随便换一个（录屏从 gpt-5.4 换到 gpt-5.2-codex）。同一个选择器在 VS Code 和 Cursor 终端里都能用，这让 "Codex 在 VS Code 里用不了" 有了最快的修法。
Codex v0.114.0 在 VS Code 里打开的 /model 选择器在 2:20 观看 - 11
重新提问，再切回来
TUI 确认 "Model changed to gpt-5.2-codex medium"，状态行显示 gpt-5.2-codex medium · 100% left。把提示词再发一遍——录屏里的会话紧接着就恢复正常流式了——请求完成后可以 /model 切回偏好的模型。这个"切走再切回"就是社区对付间歇性流报错的办法。
TUI 里确认 "Model changed to gpt-5.2-codex medium"在 2:24 观看
Windows 与 mac 快速检查
- 12
Windows 与 mac 的平台快速检查
Windows 上，保持 Git for Windows 在装（sh 修复的前提），升级后还是起不来就修复 Microsoft Visual C++ 运行库——两者都是有据可查的 Windows 修法。macOS 和 Linux 上，在新终端跑 codex --version 确认 PATH，拿不准就用官方脚本重装。两个平台都一样："Codex 今天用不了" 上 status.openai.com 几秒钟就能分清是你的问题还是 OpenAI 的问题。
还是不行？升级后排查清单
大多数 "codex 更新后用不了" 都落在这几类里。按顺序排查——从本页演示过的状态文件开始，到值得读的发布说明收尾。
- 1更新写坏的配置：一次失败的更新写出的 config.toml 会让每次启动都崩。关掉 Codex，在管理员 PowerShell 里删掉（或改名）%USERPROFILE%\.codex\config.toml——下次启动 Codex 会写一份新的。已经跑过命令产生的红色报错无害。
- 20.162.1 的启动失败：在这个 stable 版本（2026 年 10 月 9 日）之前，后台服务器的功能配置与 CLI 默认值不一致时 Codex 可能拒绝启动。修复随 0.162.1 发布——"兼容性检查现在只对显式命令行功能覆盖生效"（#52648）——所以修法是升级，不是改配置。
- 3多行 TUI 崩溃：0.162.1 还"修复了异步提问包含多行时的 TUI 崩溃，保留换行与完整超链接目标"（#51866）。如果你的 Codex 粘贴多行提示就崩，0.162.1 了结了它。
- 4故障还是本地问题："Codex 今天用不了""现在用不了"多半是 OpenAI 的锅——状态页横幅会明确列出 Codex 故障，全线亮绿的状态页才是"修好了"该有的样子。
- 5无视更新横幅：TUI 会打印 "Update available! 0.114.0 -> 0.116.0" 和发布说明链接——这么老的版本错过了几个月的流与登录修复。从横幅链接或安装脚本重装。
- 6还是没救：截下 codex --version 和 ~/.codex/log 里最新的日志（Windows 是 %USERPROFILE%\.codex\log），带上流报错里的请求 ID，再到 github.com/openai/codex 提 issue 时附上 ~/.codex/sessions 里的会话记录。
按顺序做完——升级、状态重置、登录重置、流重试、模型切换——本月几乎所有 "codex not working" 报告都覆盖了。全都无效时，请求 ID 加最新日志文件就是维护者最先要的东西。