在 Codex CLI、VS Code 扩展或桌面端中界面长时间停留在Thinking不代表模型一定还在正常处理也不代表任务已经失败。有些情况下后端任务仍在运行只是进度流没有回到界面有些情况下请求没有发出另一些情况则是工具调用、会话状态或本地客户端卡住。本文围绕codex 一直正在思考、Codex 卡在 thinking等现象给出一套不会重复提交任务的排查流程。重点是先保护当前任务状态再区分网络流中断、界面刷新、工具调用和本地会话问题。一、Thinking 状态不等于同一种故障可以先观察三个信号是否出现新的工具调用、文件变更、终端输出或进度信息。Stop、取消或返回按钮是否仍然可用。重新打开会话后原任务是否出现新的输出或完成结果。如果任务仍有文件变更、终端输出或资源消耗贸然重启或重复提交可能产生两个并行任务。官方仓库的公开问题中有用户反馈任务实际仍在运行但界面停留在 Thinking重启后可见的进度记录并不完整。因此第一步不是连续点击重试而是确认有没有正在进行的任务。二、最小请求区分客户端问题和项目问题关闭容易触发长时间工具调用的项目打开一个空目录或只读测试目录。发送一个明确限制范围的短请求请只返回 OK不读取文件不执行命令也不要修改项目。结果可以分为三类空目录中的短请求正常原项目卡住重点查看项目规模、工具权限、MCP 服务、终端进程和任务上下文。空目录也卡住但 CLI 正常优先检查 VS Code 扩展或桌面端界面状态、扩展版本和本地会话恢复。CLI、VS Code 和桌面端都卡住检查认证、DNS、HTTPS、代理、服务状态和客户端版本。这个测试的价值在于减少变量。不要一边改网络、一边升级扩展、同时重新发送原任务否则无法判断是哪项变化带来了结果。三、任务可能仍在运行时不要重复提交如果 Thinking 界面没有明显进度但任务刚刚涉及代码修改、文件扫描或外部工具先做低风险确认查看项目目录是否出现预期的文件变化。查看相关终端窗口是否还有进程输出。检查 VS Code 的输出面板和扩展日志入口。观察是否出现新的文件锁、子进程或工具调用记录。确认前不要重新发送相同提示词也不要同时打开多个副本继续操作。公开问题中曾出现“原任务已接受、界面却像没有发送”的情况重复发送会造成两个任务并行后续还可能出现会话找不到、改动重复或结果覆盖。四、判断是不是响应流中断Thinking 状态与Reconnecting...经常连续出现但处理方式不同。若界面随后出现以下文字重点转向传输层stream disconnected before completionReconnecting... 1/5error sending request请求发送后长时间没有任何响应这时可以在启动 Codex 的同一个终端执行基础检查codex --version Resolve-DnsName chatgpt.com Test-NetConnection chatgpt.com -Port 443 curl.exe -I -L --connect-timeout 5 --max-time 15 https://chatgpt.com/解释结果时要区分层级DNS 失败是解析问题TCP 443 失败是端口或出口问题TLS 错误需要检查系统时间、证书链和企业网络策略收到 HTTP 状态码则说明请求已经到达 HTTP 层。401 或 403 不能直接说明“网络完全不通”还需要结合登录状态和应用返回内容判断。五、检查 VS Code 与 CLI 的版本和运行环境VS Code 扩展、Codex CLI 和桌面端可能不是同一个版本也可能使用不同的配置目录。不要只在系统终端查看版本要在 VS Code 集成终端和实际启动 Codex 的终端各执行一次where.exe codex codex --version Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue如果where.exe codex指向多个目录说明系统可能存在多个安装来源。此时先确定 VS Code 实际调用的路径再决定是否更新。通过 npm 安装的 CLI 可以查看包版本npm list -g openai/codex --depth0不要因为一次 Thinking 就直接删除配置目录。配置和会话文件可能包含排查所需的信息删除前应先备份并确认任务已经结束。六、代理、DNS 与长连接的检查方法浏览器能工作不代表 VS Code 扩展能使用相同的代理。扩展可能继承系统设置也可能只读取启动进程的环境变量。先查看当前进程能看到什么Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue如果所在网络要求使用 HTTP CONNECT 代理可在当前终端进行一次临时验证$env:HTTP_PROXY http://127.0.0.1:7890 $env:HTTPS_PROXY http://127.0.0.1:7890 code .示例中的端口需要替换为实际配置不能照抄。目标站点使用 HTTPS也不意味着代理地址必须写成https://不少 HTTP 代理通过 CONNECT 建立 HTTPS 隧道。若客户端提示代理协议不支持应以当前客户端文档和企业网络规范为准检查协议头、认证方式和端口。长任务卡住时还要考虑代理或安全设备对持续连接、空闲时间、响应缓存和 TLS 检查的影响。短命令成功只能说明短连接可用不能证明长时间的流式响应一定不会被中断。七、工具调用和 MCP 服务导致的等待如果短文本请求能返回只有“读取项目”“运行测试”“调用 MCP 服务”这类任务停在 Thinking问题范围就不应只放在模型或网络上。可以做三组对照不调用工具只要求返回固定文本。允许读取一个小文件但不执行命令。单独启用一个已确认可用的工具再逐步增加工具。每次只改变一个条件。若某个工具一启用就复现检查它的进程是否退出、端口是否监听、权限是否足够、返回是否符合协议以及是否存在等待外部输入的交互式命令。工具没有返回时界面可能持续显示 Thinking但根因并非模型生成速度。八、会话恢复与本地状态系统崩溃、VS Code 强制退出、网络中断或扩展升级都可能让本地界面与远端任务状态暂时不一致。此时建议按以下顺序处理先确认任务没有继续修改文件或运行进程。记录当前会话名称、错误文本、版本和发生时间。关闭当前任务视图重新打开原会话观察是否恢复进度。仍然无响应时再重启扩展或应用。重启后不要立刻重复发送原任务先查看历史状态和工作区差异。公开问题中有“重启后进度记录不完整”的反馈所以重启是恢复界面的一种手段不应被当成确认任务失败的依据。对有文件修改权限的任务重启前最好保留 Git 状态和终端输出。九、按症状快速定位1. 一发送任何短提示词就 Thinking用空目录最小请求复现。如果 CLI、扩展和桌面端都失败优先查认证、服务状态、DNS、443 端口、代理和版本如果只有一个客户端失败优先查该客户端的版本和会话状态。2. 只有长任务或工具任务 Thinking检查工具进程、MCP 服务、终端命令是否等待输入以及长连接是否被中间设备关闭。把任务拆成只读、小范围、单工具步骤不要继续堆叠上下文。3. 重启后原任务状态异常先查看文件实际变更和 Git diff再决定是否继续。不要依据界面上“没有显示完成”就重复执行可能产生副作用的命令。4. Thinking 后转为 Reconnecting按连接流中断处理查看完整错误文本执行 DNS、TCP 和 HTTPS 测试检查代理变量并确认服务状态。若最终为 401处理登录若是 429处理用量或限流若是流中断处理长连接和传输路径。十、反馈问题时保留哪些信息官方 Codex 问题讨论中维护者曾建议使用/feedback上传日志并提供 thread ID。反馈前应脱敏只保留定位所需信息客户端类型和版本。操作系统、VS Code 版本以及是否使用 WSL。发生时间、所在时区和最小复现步骤。是所有请求失败还是某个项目/工具失败。DNS、TCP 443、HTTPS 测试结果。完整错误文本、请求 ID 或 thread ID。不要提交 API key、Cookie、认证文件、代理密码、私有仓库代码或包含客户数据的日志。日志中若出现项目路径、域名和账号信息也应先做脱敏处理。十一、总结Codex 一直显示 Thinking先要确认它是“任务仍在运行但界面没有更新”还是“请求、工具或会话已经卡住”。空目录最小请求可以把项目因素排除版本、认证、DNS、HTTPS 和代理检查可以定位连接因素工具和 MCP 对照测试可以定位本地调用因素。排查过程中最重要的是避免重复提交有副作用的任务。保留版本、日志、时间和实际文件变化通常比反复重装、刷新或重新发送提示词更安全也更容易让问题得到有效处理。参考资料OpenAI Codex 官方仓库Codex CLI 官方文档VS Code Codex 卡在 Thinking 的公开问题Codex 桌面端 Thinking 状态异常的公开问题