Codex Windows 客户端有进程却不出窗口，我会先查什么

发布于: 2026-09-11 更新于: 2026-09-11

如果 Codex 双击后没窗口，任务管理器里却已经有进程，我会先记下版本和日志，不急着卸载重装。单凭“打不开”这三个字，还分不清是客户端启动出了问题，还是登录、网络或其他环节卡住了。

我查到一条可以拿来对照的线索：9 月 4 日，有用户在 openai/codex 仓库报告，Windows 上的 Codex 26.901.2854.0 启动后只有进程，没有主窗口。这是用户提交的故障报告，不代表 OpenAI 已经确认根因或影响范围。查看原始 issue

这里先说清一个容易混淆的地方：报告者的安装包是 OpenAI.Codex，但显示名称和进程里出现了 ChatGPT。因此，这篇讨论的是该报告中的 Codex 桌面端问题，不能把它当成所有 ChatGPT Windows 客户端的通用排查结论。

我会先把现象记下来

我的排查顺序是：先确认是哪一个应用、哪个版本出了问题，再看日志，最后决定能否换个入口继续工作。

桌面端打不开排查顺序

排查顺序示意图，不代表已经确认的修复方案。

如果设置窗口还能打开，可以直接查看版本；完全打不开时，我会先查 Windows 的已安装应用信息。然后打开任务管理器，记录进程名称、是否有窗口，以及 CPU 占用有没有持续偏高。截图时注意遮住账号、路径中的个人信息和其他无关窗口。

这一步我不急着下结论。进程名相同不代表故障相同，版本相近也不能证明一定受影响。把这些信息放在一起，才方便和公开报告比较。

原报告还提供了一个辨识度比较高的错误：

1	Artifact Session host Unix-socket transport is not available on Windows

报告者在带详细日志的启动过程中看到了它。如果你已经取得日志，可以搜索这段文字；找不到也别强行往这个问题上套。相同报错是一条排查线索，仍然不是根因诊断。报告中的日志与环境

我建议保留一份简短记录，后面查 issue 或反馈时都用得上：

Windows 版本及 build：
Codex 客户端版本：
第一次出现问题的时间：
是否刚更新过客户端：
进程是否出现，窗口是否出现：
Web 端是否正常：
Codex CLI 是否正常（如已安装）：
日志中的完整错误及时间：
已经尝试过的操作和结果：

每试一个办法就补一行结果。这样至少不会隔几分钟又把同一个操作重复一遍，也更容易发现究竟是哪一步改变了现象。

那位报告者尝试过重新安装、清理缓存等操作，但没有解决自己的问题。这只能说明这些办法在他的环境里没奏效，不能推断你的电脑也一定如此。

对我来说，更值得避免的是一次性改很多东西：刚清完缓存，又重置应用，再去动系统组件。就算最后恢复了，也难以知道哪一步起了作用。尤其当你准备反馈故障时，先保留日志和配置，再考虑会清掉现场的操作。

报告者提到，同一账号的 Web 端以及 Codex CLI 仍能使用。我会在自己的环境里分别验证，而不会直接照搬这个结果。如果其中一个入口正常，且能完成手头的任务，就先用它继续工作。

Web 能打开，只能说明这个入口在当时可用；它不能完全排除桌面端自己的登录或网络问题。类似地，CLI 能运行，也不代表桌面端的全部能力都有替代品。要不要切换，还是看你眼下具体需要做什么。

至于“是不是最近更新引起的”，我会保留判断。OpenAI 的 9 月 3 日发布说明里有 Codex 浏览器和电脑使用策略相关变更，但那不是这条启动故障的修复公告，也没有建立两者的因果关系。OpenAI 发布说明

如果你的版本、现象和日志都与原报告接近，可以继续关注那条 issue；如果 Web 也异常，或者根本没有进程，就应另外排查。先把问题范围缩小，比急着认定“就是同一个 bug”更有用。

AI 辅助整理，经资料核对 · 2026-09-11

--- 本文结束 The End ---