如果你使用Codex或ChatGPT Work进行开发任务，可能遇到过这样的情况：普通ChatGPT聊天完全正常，但切换到Work或Codex模式后，消息迟迟没有响应，界面反复显示Reconnecting，依次尝试1/5、2/5，直到5/5才可能得到回复。

这种情况比较容易让人误以为是模型响应慢、账号异常或者Codex本身出现故障。实际上，如果电脑已经开启系统代理，浏览器和普通ChatGPT聊天都能正常使用，那么可以优先检查Codex运行环境是否正确使用了当前代理。

有一种比较直接的处理方式，就是让Codex自己检查电脑的代理设置和网络配置，在确认问题后再进行必要的修改。这样不需要一开始就手动修改大量配置文件，也能减少误改模型、登录信息或其他设置的风险。

Codex一直Reconnecting 5/5怎么办？简单修复指南

为什么ChatGPT正常而Codex一直重连

很多用户会产生一个疑问：既然ChatGPT普通聊天可以正常发送和接收消息，为什么同一个软件里的Work或Codex却无法连接？

原因在于，普通聊天与Codex的工作执行并不完全使用相同的网络请求流程。Codex除了需要与模型服务通信，还需要维持任务执行过程中的持续连接和数据传输。

其中一个重要环节是WebSocket连接。根据OpenAI官方网络配置说明，部分ChatGPT和Codex功能除了使用普通HTTPS请求，还需要通过安全WebSocket连接传输数据。

Codex模型响应和流式数据传输涉及的WebSocket目标地址为 wss://chatgpt.com/，需要允许通过TCP 443端口建立连接，并且代理或防火墙必须正确处理WebSocket的Upgrade握手。

如果系统代理只对部分网络请求生效，或者代理程序没有正确处理Codex所使用的连接，就可能出现普通聊天正常、Codex持续重连的情况。

系统代理未必会被Codex自动采用

这是排查此类问题时值得优先关注的地方。

电脑开启系统代理，并不代表所有桌面应用和内部运行组件都会自动采用相同的代理设置。不同程序可能使用不同的网络库，也可能从系统代理、环境变量或自身配置中读取网络参数。

OpenAI当前的Codex配置文档提供了一个名为 features.respect_system_proxy 的实验性设置，用于让ChatGPT桌面应用和Codex使用的原生运行时遵循操作系统代理设置。

这个设置的默认值为 false。对于需要依赖系统代理或PAC自动代理配置的设备，可以主动启用它。

这里需要纠正一个容易产生误解的说法：不能简单认为所有Codex重连5/5都是因为它固定先直连失败5次，然后才自动切换系统代理。官方文档确实说明存在独立的 system_proxy_fallback 机制，但它主要覆盖部分登录和云端配置请求，并不意味着所有Codex模型连接都会按照相同的顺序自动切换。

因此，系统代理识别问题是一个值得优先检查的方向，但不能仅凭重连次数就确定故障原因。

直接让Codex检查并修复代理设置

如果你已经开启系统代理，并且普通ChatGPT聊天可以正常使用，可以先将下面这段提示词直接复制给Codex或ChatGPT Work。

请检查我电脑当前的系统代理设置，以及 Codex
运行环境是否正确使用了它。

如果发现 Codex 没有正确采用当前系统代理，
请先分析原因，再提出最小范围的修复方案。

具体要求：

1. 检查当前系统代理地址、端口和代理运行状态。
2. 检查 Codex 是否能够识别并使用系统代理。
3. 检查相关环境变量和 Codex 网络配置。
4. 检查是否存在 WebSocket 连接失败或代理路由异常。
5. 如果确认是代理配置问题，请先备份原有配置。
6. 优先使用官方支持的系统代理配置方式。
7. 不要修改模型、账号登录、认证信息、
   自定义 API 地址以及其他无关配置。
8. 不要输出任何密钥、Token、Cookie 或个人凭据。
9. 修改前说明准备修改的文件和具体内容，
   等待我确认后再执行。
10. 修改完成后验证代理连通性，
    并告诉我如何重启 Codex 和恢复原设置。

如果检查后发现并不是代理问题，
请不要盲目修改配置，继续根据网络连接日志
排查 WebSocket、防火墙、DNS 和其他可能原因。

这段提示词的重点，是让Codex先检查，再决定是否修改，而不是直接覆盖网络配置。执行过程中，如果Codex需要读取配置文件或修改系统设置，可能会弹出相应的权限请求。

建议先查看它准备执行的操作，确认修改范围合理后再允许。尤其要注意，不要让它输出或覆盖登录凭据、API密钥等敏感信息。

手动启用Codex系统代理配置

如果希望自己处理，也可以直接检查Codex的用户级配置文件。

默认情况下，Codex的用户配置文件位于：

~/.codex/config.toml

Windows用户通常可以在用户目录下找到对应文件，例如：

%USERPROFILE%\.codex\config.toml

打开文件后，在配置中添加以下内容：

[features]
respect_system_proxy = true

这个配置的作用是允许Codex原生运行时采用操作系统代理设置。需要注意，如果原来的config.toml已经存在 [features] 配置段，不要重复创建一个同名配置段，只需要将 respect_system_proxy = true 合并进去即可。

还有一个细节：根据OpenAI官方文档，这个设置不能通过项目目录下的本地 .codex/config.toml 启用，应放在支持的用户级配置或管理配置来源中。

修改完成后，需要完全退出并重新启动Codex或ChatGPT桌面应用，让新的网络配置生效。仅关闭当前聊天窗口或新建对话，未必能够让运行时重新读取配置。

系统代理无法识别时检查环境变量

如果已经启用系统代理配置，但Codex仍然无法正常连接，可以进一步检查HTTP代理环境变量。

Codex运行时在无法完成系统代理解析时，可以使用明确设置的代理环境变量；如果没有可用的系统代理解析结果或环境变量，则可能采用直接连接方式。

常见的代理环境变量包括：

HTTP_PROXY=http://127.0.0.1:7897
HTTPS_PROXY=http://127.0.0.1:7897
ALL_PROXY=http://127.0.0.1:7897
NO_PROXY=localhost,127.0.0.1,::1

这里的7897只是一个示例端口。不同代理软件的HTTP或Mixed端口可能是7890、7897、10809或其他数值，必须以自己代理软件显示的实际端口为准。

部分Windows用户反馈，将代理环境变量写入Codex的用户环境文件 ~/.codex/.env，然后完全重启ChatGPT桌面应用，可以解决Work模式反复重连的问题。不过，这属于特定环境下的用户反馈，不能保证适用于所有系统和版本。

如果准备采用这种方式，应该先确认当前Codex版本支持相应的环境配置方式，并检查本地代理端口确实处于监听状态。不要直接复制其他人的代理地址，更不要将代理环境变量指向已经停止运行的本地端口。

WebSocket连接异常也可能导致重连

如果系统代理配置没有问题，还需要检查WebSocket连接是否被代理软件、防火墙或网络安全程序拦截。

普通HTTPS请求能够正常访问，并不代表WebSocket连接一定可以建立。WebSocket需要经过特定的Upgrade握手，建立连接后还需要保持持续的数据传输。

OpenAI官方网络建议中明确指出，Codex相关连接需要允许以下通信：

  • 目标地址：wss://chatgpt.com/

  • 通信端口：TCP 443。

  • 连接方式：允许标准WebSocket Upgrade握手。

  • 连接维护：避免代理或防火墙过早关闭持续连接。

如果使用了网络过滤、HTTPS流量检查或TLS解密功能，还需要确认这些功能没有修改WebSocket握手内容，或者提前关闭长连接。

尤其是部分代理软件，普通网页访问没有问题，但对持续连接的空闲超时、消息大小或连接保持策略设置不合理，仍然可能导致Codex在任务执行过程中断开。

这种情况下，单纯修改Codex的系统代理设置不一定能够解决问题，还需要结合代理日志和网络连接记录进行判断。

参考资料

  1. OpenAI官方文档：Codex系统代理与网络配置说明

  2. OpenAI官方文档：Codex config.toml基础配置

  3. OpenAI帮助中心：ChatGPT与Codex网络连接排查建议

  4. GitHub案例：Windows下Codex Work使用系统代理后仍然重连的问题

  5. OpenAI官方服务状态页面