Codex VS Code 扩展提示词消失或一直排队，怎么办？

有用户报告，Codex 的 VS Code 扩展有时会在提示词消失后不启动任务，或让后续消息一直停留在队列中。遇到这些现象，不应只归因于电脑设置或网络，也需要检查扩展如何处理请求。不过，相似的报告并不能证明所有情况都有同一个已确认的原因。

本文说明如何在保护现有工作的前提下检查与处理问题，并区分用户报告和官方排查建议。重新发送可能导致重复执行，因此应先核对实际结果。

响应慢与请求没有启动是两回事

Codex 读取代码或运行工具可能需要时间。任务已出现在对话中且持续更新，与输入框清空后没有出现新任务，是不同情况。反过来，一段时间没有可见进展，也不能证明请求已经永久丢失。

• 只有输入框被清空：检查刚发送的提示词是否出现在对话中。
• 后续消息一直排队：检查上一个任务是否真正结束，以及是否还有待处理的项目。
• 已完成的请求再次显示为待处理：对照界面与实际执行结果。
• 重启只暂时有效：记录相同条件是否再次触发问题，不要直接认定已经修复。

例如，修改文件的请求没有出现在对话中时，应先检查文件变化和正在运行的工作，再考虑重发。看不到消息，本身不足以证明没有执行任何操作。

GitHub 上具体报告了什么？

OpenAI Codex 仓库中有以下用户报告。创建日期采用 GitHub 公开记录中的协调世界时（UTC）日期。报告者所用的环境，不能直接推广到所有用户。

来源：首次发送问题 #50075、流式状态持续问题 #50486、Windows 消息与队列问题 #50491和发送与待处理状态问题 #50653。

这些记录证明其他用户描述过类似现象。提交 Issue 不等于开发者已经复现或确认原因。即使 Issue 关闭，也需要看关闭理由：可能是重复报告，而不是已修复；某次修复也可能只适用于部分版本。

例如，#50653 的一条10月4日评论称，更新到 26.930.41038 后似乎有所改善，但仍在测试。这是个人的阶段性反馈，并非开发者确认该版本能解决所有情况。10月28日查询时，上述四条 Issue 仍全部开放。

后续提示词为什么可能一直排队？

一种可能解释是，任务实际已经完成，但扩展内部状态没有同步。#50486 中的用户日志报告，在对话轮次完成的同时，仍有 markedStreaming=true 标记，以及释放队列消息锁时的错误。流式响应指逐步接收回答；该报告中的标记用于描述扩展仍把任务视为活动状态的情况。

来源：处理状态持续存在的用户报告。

下面的简化流程用于说明状态不一致可能如何影响后续请求。它是解释性示例，不是已经验证的扩展实现图。

已经确认的事实，是存在相似现象的报告。状态管理问题是报告中提出的解释，尚不能作为所有案例的确定原因。不同案例是否共享该原因、您的环境是否受到影响，都需要更多证据。认证或连接失败也可能表现相似，因此不能在未查看相关日志时锁定单一原因。

服务状态正常时，也可能发生吗？

可能。官方状态页适合用来查找大范围服务事件，但不保证每个扩展版本和个人环境都没有错误。OpenAI 说明，可用性指标采用汇总数据，个别客户的实际可用性可能不同。应把事件历史、受影响服务与故障发生时间进行对照。今天的服务状态不能证明之前的请求已经成功。

来源：OpenAI 服务状态。

在同一账户的另一个客户端发送简短请求，有助于缩小排查范围。如果反复只有扩展失败，而应用或命令行界面（CLI）正常，就有理由优先调查扩展相关问题。如果多个客户端失败，还应考虑服务、认证、使用额度或连接问题。单次成功或失败都不能证明原因。

如何按顺序排查并保护工作？

以下是实用检查步骤，不是官方补丁，也不保证解决问题。如果丢失的请求涉及删除、发布或部署，应先确认实际结果，再考虑重新发送。

1. 检查审批等待和请求状态。如果 Codex 正等待权限或用户输入，查看对应请求并作出必要决定。加载动画本身不能证明故障。保留提示词、时间及其时区、最后一次成功响应和可见待处理项目，并检查新提示词是否已登记到对话。
2. 核对真实变化。文件工作应检查文件修改与正在运行的终端；外部服务应到对应服务查看结果。不要反复提交相同请求。
3. 保护已有工作。保存尚未保存的文件。使用 Git 时，先检查改动，再只提交预期的工作，或另做备份。重启前，尽可能确认活动任务已经完成或停止。Git 变化也可能来自更早的工作或其他工具，应查看具体内容，不能把存在改动当作最后一次请求已经执行的证明。
4. 完全关闭并重新打开 VS Code。重新加载窗口无效时，关闭相关窗口后重新启动。不要首先强制结束进程，以免丢失未保存工作。
5. 在新对话中测试简短、不修改数据的提示词。先要求用一句话解释，再发送后续问题。若正常，再逐项加入发生问题时的条件，例如图片附件。
6. 比较客户端并查看修复进展。使用同一账户，尽可能选同一模型，但不要在别处同时重跑结果不明的工作。检查扩展更新和相关 Issue 的后续信息。

OpenAI 故障排查指南也建议检查审批、终端基本运行情况，以及在新对话中使用更小、更聚焦的提示词。一个不修改数据的例子是：“不要修改文件或运行命令，用一句话解释 HTML”，再追问“把解释缩短一些”。HTML 是用于组织网页的超文本标记语言。确认两条提示词都已登记，且各产生一次回答。这项检查不会重复原来的任务。

测试成功并不证明原来的 bug 已修复。应把与故障有关的条件，例如附件或排队的后续消息，逐项加入；再次失败时记录最后一次变化和时间。不要使用发布、删除或部署作为诊断任务。

#50491 的作者报告，完全重启能暂时改善，而重新加载窗口并不总是有效。这是可评估的临时办法，不是永久修复，也不保证适用于每个环境。

来源：关于重启 VS Code 效果与限制的报告。

什么时候考虑比较旧版扩展？

如果问题紧接更新出现，重启也无法继续工作，可以考虑临时对比以前用过的版本。本文没有确定一个经过验证的修复版本，也没有指定对所有人都稳定的旧版。应先记录当前版本、发布渠道和相关设置。

先检查已安装版本及官方分发渠道提供的更新。在 Extensions 视图中，Show Extension Updates 或 @updates 筛选器会列出可用更新。对相关扩展使用 Update，并按提示执行 Restart Extensions。比较旧版只是记录当前故障后的临时诊断选项。

在 Windows 上，用 Ctrl+Shift+X 打开 Extensions，找到 OpenAI 的 Codex 扩展。右键点击它，选择 Install Another Version，再选择可用版本。必要时，只为这一个扩展临时关闭 Auto Update。

要恢复更新后的版本，应更新扩展并重新启用自动更新。旧版本可能缺少修复，或不兼容新设置，不应作为永久方案。先用只读请求测试；如果对比后情况更差，恢复之前记录的版本和设置。

来源：VS Code 关于扩展版本和自动更新的文档。

问题持续时，需要收集哪些信息？

准确时间和可复现的顺序，比只说“扩展卡住”更有帮助。收集以下信息时，不要分享密码、认证令牌、API 密钥或私人文件内容。API 是应用程序编程接口，用于让软件访问其他服务。

• Codex 扩展版本与发布渠道、VS Code 版本以及操作系统。
• 模型、认证方式、故障时间和时区。
• 触发故障的顺序，包括任务完成和发送后续消息的过程。
• 是否在新对话、附带图片或排队发送后续消息时出现。
• 完全重启前后、其他客户端上的结果。
• 同一时间段的相关错误，以及已遮挡敏感信息的截图。

最小报告可描述为“新对话 → 第一个只读问题 → 响应完成 → 发送后续消息 → 输入清空但没有登记新提示词”。最后一项应改成实际观察。将预期行为，例如后续消息被登记并且只执行一次，与实际界面、日志和文件变化分开。不要把他人的日志当成自己的，也不要仅凭该顺序断定原因。

在 VS Code 中打开 View → Output。如果有 Codex 或 OpenAI 输出通道，查看故障发生的时间段。通道名称与可用性可能因版本不同而变化。若出现 401、429 或连接中断，应保存时间和前后文，不要认定一个错误码能够解释全部问题。

已有 Issue 与您的现象和环境一致时，可以将其作为参考。新报告应区分预期行为与实际行为，并提供最小复现步骤。修复公告出现后，核对版本和适用范围，再重新测试之前失败的对话流程。