Codex 桌面端反复显示 "Reconnecting..."、重试计数从 1/5 走到 5/5 然后循环------这个问题在国内网络环境下的最常见根因是：macOS 从 Finder/Dock 启动的 GUI 应用不会继承你写在 ~/.zshrc 里的代理环境变量，导致 Codex app-server 绕过了本地代理直连 OpenAI，连接全部超时 。这不是猜测，是 GitHub Issue #30695（2026-06-30）复现验证过的结论，且有确认可行的修复方案：用 launchctl setenv 把代理变量注入用户级 launchd 环境，完全退出并重启 Codex 后，重试事件归零。本文给出这条主路径的逐步操作、验证方法（codex doctor），以及排除法覆盖的其他三类 Reconnecting 场景（长任务流断开、WebSocket 提前关闭、Windows 远程配对超时）。
症状确认：你的问题是不是这一个
先对号入座。Issue #30695 记录的典型症状：
- 对话界面反复出现 "Reconnecting..." ，约 15 秒一轮重试
- 重试计数 1/5 → 5/5 循环往复
- 日志中出现
codex_core::responses_retry事件 - 关键鉴别点 ：同一台机器，终端里的 Codex CLI 正常，桌面 App 不正常 ；或 App 从终端
open启动正常、从 Finder/Dock 点图标启动就断连
最后一条如果符合，基本可以锁定是 GUI 代理环境变量问题，直接看下一节。不符合的看本文后半部分的排除法。
根因：GUI 应用不读你的 .zshrc
复现链条（Issue #30695 报告者的分析，官方标签已确认为 bug）：
- 你的网络访问 OpenAI 需要本地代理（如
http://127.0.0.1:7890） - 代理变量
HTTP_PROXY/HTTPS_PROXY只写在~/.zshrc里 - 终端进程会加载
.zshrc，所以 CLI 一切正常 - Finder/Dock 启动的 GUI 应用走 launchd，不加载交互式 shell 配置
- Codex app-server 拿不到代理变量 → 直连 OpenAI → 全部超时 → 无限 Reconnecting
这是 macOS 的机制问题，不止 Codex，任何依赖代理的 GUI 开发工具都可能踩到。
修复：launchctl setenv 三步走（已验证）
第 1 步：注入代理变量到 launchd 用户环境
把 127.0.0.1:7890 换成你自己的代理地址端口：
bash
launchctl setenv HTTP_PROXY "http://127.0.0.1:7890"
launchctl setenv HTTPS_PROXY "http://127.0.0.1:7890"
launchctl setenv http_proxy "http://127.0.0.1:7890"
launchctl setenv https_proxy "http://127.0.0.1:7890"
launchctl setenv NO_PROXY "localhost,127.0.0.1"大小写都要设------不同组件读取的变量名大小写不一致。
第 2 步：完全退出并重启 Codex
注意是 Cmd+Q 完全退出（Dock 图标右键 → 退出），不是关窗口。launchd 环境变量只对重启后新建的进程生效。
第 3 步：验证修复
bash
codex doctor --jsonIssue 中记录的修复成功标志：
- WebSocket 握手返回
HTTP 101 Switching Protocols - transport 初始化时
reconnectAttempt=0 - 不再产生新的 retry 事件
两个注意事项：
launchctl setenv是会话级的------注销或重启系统后失效，需要重新执行。想持久化，把这几条命令做成登录时运行的 LaunchAgent，或写个 alias 一键执行- 撤销方法：
launchctl unsetenv HTTP_PROXY（每个变量各执行一次）
已确认无效的路径 ：给自定义 provider 设置 supports_websockets = false 不能解决此问题------gpt-5.5 会直接报模型不支持错误（Codex-Responses-Lite header 限制，另案 #30224 跟踪中）。
不是代理问题？其他三类 Reconnecting 场景排除法
如果终端 CLI 同样断连，或者你不在需要代理的网络，按下表排查：
| 场景 | 特征 | 对应 Issue | 处理 |
|---|---|---|---|
| 长任务流断开 | 长时间运行的任务中途 "stream disconnected before completion" | #30997 | 官方未修复；缓解：大任务拆小、避免单轮超长生成 |
| CLI WebSocket 提前关闭 | CLI 反复重连后降级，websocket 在 response.completed 前关闭 | #30933 | 网络链路不稳定信号；换稳定出口后重试 |
| Windows 远程配对超时 | 模型思考中超时 + remote pairing/reconnect 失败 | #30590 | 官方未修复；避免在思考中断开远程会话 |
| SSH 认证失效死循环 | 桌面端反复重试已认证失败的 SSH 连接不退避 | #31080 | 手动断开该远程连接，重新认证后再连 |
另一个容易混淆的问题：App 冻结（不是 Reconnecting）。如果 Codex 在使用内置浏览器插件时整个界面卡死、无法输入，那是 #30624（日志里会有上万条 "app-server initialize handshake timed out"）------只能强制退出重启，官方未修复；缓解方法是让 Codex 用系统 Chrome 而不是内置浏览器做页面验证。
排查工具箱
日志位置（macOS）：
bash
# App 日志
ls ~/Library/Logs/com.openai.codex/
# 会话记录
ls ~/.codex/sessions在日志里搜这两个关键词定位问题类型：
responses_retry→ 代理/网络连接问题（本文主路径）initialize handshake timed out→ app-server 握手问题（#30624 家族）
版本核对------桌面 App 和 CLI 版本可能不同步，报 Bug 前先确认：
bash
codex --version
/Applications/Codex.app/Contents/Resources/codex --version上报问题 ：在 App 输入框键入 / 发送反馈可附带会话 ID；GitHub 提 issue 前先搜 connectivity 标签避免重复。注意：外发日志前检查其中是否含密钥和内网地址（官方文档明确提醒）。
常见问题
Q：为什么终端里的 Codex CLI 好好的，桌面 App 就不行？
终端进程加载 ~/.zshrc 拿到了代理变量；Finder/Dock 启动的 GUI 应用走 launchd，不读交互式 shell 配置。这就是两者行为差异的全部原因，也是 launchctl setenv 能修复的原理。
Q：每次重启电脑都要重新执行 launchctl setenv 吗？
是的，它是会话级设置。一劳永逸的做法：写一个 ~/Library/LaunchAgents/ 下的 plist 在登录时自动执行，或者接受每次开机跑一次脚本。官方 Issue 里请求的"App 内代理设置项"截至发稿尚未实现。
Q：系统代理（网络偏好设置）开了，为什么 Codex 还是连不上？
Issue #30695 的报告者明确请求 Codex Desktop "honor macOS system proxy settings"------也就是说当前版本（26.623.x）不读系统代理设置，只认环境变量。这正是很多人"明明开了代理还是断连"的原因。
Q：Reconnecting 循环时正在跑的任务会丢吗？
会话记录在 ~/.codex/sessions 本地保留。恢复连接后可以 resume，但注意 #30424 报告过 SSH 断连后 resume 可能产生两个分叉的 agent------恢复后先确认只有一个活跃会话在跑。
Q：国内网络下有没有不折腾代理的替代路径？
Codex 桌面端必须直连 OpenAI 服务，代理不可绕过。如果你的场景只是"要一个能干活的编码 Agent"而非必须 Codex，可以考虑走国内可直连的 API 方案（如七牛云的 Anthropic 兼容端点 + Claude Code 工具链），网络层零配置------工具选型时把"网络可达性"列为一票否决项，能省掉这整篇文章的排查。
总结
Codex 桌面端 Reconnecting 5/5 的排查决策树很短：先做鉴别 （终端 CLI 正常而 App 断连 → 代理环境变量问题）；主路径修复 用 launchctl setenv 注入五个代理变量 + 完全重启 + codex doctor 验证 HTTP 101；不匹配再走排除法 （长任务流断开/#30997、WebSocket 提前关闭/#30933、Windows 远程配对/#30590）。记住三个事实：当前版本不读 macOS 系统代理设置、launchctl setenv 重启后失效、内置浏览器冻结是另一个问题不要混淆。这些结论全部来自官方仓库 Issue 原文，修复方案在 #30695 中有完整验证记录。
据 openai/codex GitHub Issues（2026-07-02 抓取，相关 Issue 均为 Open 状态）。官方修复合入后本文方案可能不再必要，建议关注 Issue #30695 的后续动态。
延伸资源
- 国内直连的 Agent 工具链配置：https://zcn3fx96oxg4.feishu.cn/wiki/XKnIwXE4GiGtfUkeUJfcUhRAnJg