在 Codex CLI、VS Code 扩展或桌面端中，界面长时间停留在 Thinking，不代表模型一定还在正常处理，也不代表任务已经失败。有些情况下后端任务仍在运行，只是进度流没有回到界面；有些情况下请求没有发出，另一些情况则是工具调用、会话状态或本地客户端卡住。
本文围绕 codex 一直正在思考、Codex 卡在 thinking等现象，给出一套不会重复提交任务的排查流程。重点是先保护当前任务状态，再区分网络流中断、界面刷新、工具调用和本地会话问题。
一、Thinking 状态不等于同一种故障
可以先观察三个信号：
- 是否出现新的工具调用、文件变更、终端输出或进度信息。
- Stop、取消或返回按钮是否仍然可用。
- 重新打开会话后，原任务是否出现新的输出或完成结果。
如果任务仍有文件变更、终端输出或资源消耗，贸然重启或重复提交可能产生两个并行任务。官方仓库的公开问题中，有用户反馈任务实际仍在运行，但界面停留在 Thinking，重启后可见的进度记录并不完整。因此，第一步不是连续点击重试，而是确认有没有正在进行的任务。
二、最小请求区分客户端问题和项目问题
关闭容易触发长时间工具调用的项目，打开一个空目录或只读测试目录。发送一个明确限制范围的短请求：
text
请只返回 OK，不读取文件，不执行命令，也不要修改项目。结果可以分为三类：
- 空目录中的短请求正常，原项目卡住：重点查看项目规模、工具权限、MCP 服务、终端进程和任务上下文。
- 空目录也卡住，但 CLI 正常：优先检查 VS Code 扩展或桌面端界面状态、扩展版本和本地会话恢复。
- CLI、VS Code 和桌面端都卡住：检查认证、DNS、HTTPS、代理、服务状态和客户端版本。
这个测试的价值在于减少变量。不要一边改网络、一边升级扩展、同时重新发送原任务，否则无法判断是哪项变化带来了结果。
三、任务可能仍在运行时不要重复提交
如果 Thinking 界面没有明显进度，但任务刚刚涉及代码修改、文件扫描或外部工具，先做低风险确认：
- 查看项目目录是否出现预期的文件变化。
- 查看相关终端窗口是否还有进程输出。
- 检查 VS Code 的输出面板和扩展日志入口。
- 观察是否出现新的文件锁、子进程或工具调用记录。
确认前不要重新发送相同提示词，也不要同时打开多个副本继续操作。公开问题中曾出现"原任务已接受、界面却像没有发送"的情况，重复发送会造成两个任务并行，后续还可能出现会话找不到、改动重复或结果覆盖。
四、判断是不是响应流中断
Thinking 状态与 Reconnecting... 经常连续出现，但处理方式不同。若界面随后出现以下文字，重点转向传输层：
stream disconnected before completionReconnecting... 1/5error sending request- 请求发送后长时间没有任何响应
这时可以在启动 Codex 的同一个终端执行基础检查：
powershell
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 的终端各执行一次：
powershell
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 可以查看包版本：
powershell
npm list -g @openai/codex --depth=0不要因为一次 Thinking 就直接删除配置目录。配置和会话文件可能包含排查所需的信息，删除前应先备份，并确认任务已经结束。
六、代理、DNS 与长连接的检查方法
浏览器能工作，不代表 VS Code 扩展能使用相同的代理。扩展可能继承系统设置，也可能只读取启动进程的环境变量。先查看当前进程能看到什么：
powershell
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY -ErrorAction SilentlyContinue如果所在网络要求使用 HTTP CONNECT 代理，可在当前终端进行一次临时验证：
powershell
$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 对照测试可以定位本地调用因素。
排查过程中最重要的是避免重复提交有副作用的任务。保留版本、日志、时间和实际文件变化，通常比反复重装、刷新或重新发送提示词更安全，也更容易让问题得到有效处理。