技能介绍

要解决的问题

Codex 通过本地代理连接模型服务时，一旦网络中断（Wi-Fi 切换、VPN 重协商、代理进程重启），代理路由可能变成「陈旧」状态：浏览器等其他程序恢复正常，唯独 Codex 持续重试。典型日志特征是 responses_websocket 反复出现、retry 1/5 一直到 5/5、Connection reset by peer，最终静默降级为 HTTP。重试间隔会明显拖慢响应，且容易误判成供应商侧故障。

技能如何工作

核心思路是不改配置、只补路由：先确认症状，再定位真正在监听的代理端口，然后显式写入代理环境变量，最后重启进程验证。

先诊断再动手：确认浏览器流量正常而 Codex 单独重试；在日志中查找 responses_websocket、retry x/5、Connection reset by peer 等特征。
定位活跃代理端点：检查代理程序实际的 HTTP 或 mixed 监听端口，不要假设某台设备上一定是 http://127.0.0.1:7892，以实际监听为准。
保留现有配置：不修改 ~/.codex/config.toml；不为了设置 supports_websockets = false 而新增自定义模型供应商——改变供应商身份会隐藏 Codex Desktop 中已有的任务历史。写入前先检查 ~/.codex/.env，无关键原样保留。
显式代理路由：运行技能自带脚本，只更新 HTTP_PROXY、HTTPS_PROXY、NO_PROXY 三个键；内容变化时生成带时间戳的备份，原子写入，config.toml 不受影响。
完全重启验证：Codex 在启动时才加载 .env，必须彻底退出后重开。验证任务列表仍在；发送一次请求、中断并恢复网络、再发一次，确认五次重试延迟消失。
如实报告：本修复是让 WebSocket 通过显式代理路由重连，并非强制切到 HTTP 流式；WebSocket 仍可能正常成功。

适用边界与注意点

绝不写入猜测或未在监听的代理端口，否则可能让 Codex 完全无法连接。
凭证不得出现在聊天或日志中，脚本会在状态输出里对凭证做脱敏。
网上流传的 CODEX_* 禁用 WebSocket 方案属于版本相关行为，某些构建会过滤从 ~/.codex/.env 加载的 CODEX_ 键，需对照当前安装版本验证。
若显式路由无效，应继续排查残留代理进程、VPN/TUN 状态、防火墙、TLS 拦截、DNS 以及代理本身的 WebSocket 支持，而不是反复修改供应商配置。