问题根源是WebSocket未正常走代理，需先确认Node≥v18.17.0、npm＞9.0、codex命令可稳定执行；再通过--no-websocket临时禁用或配置config.toml永久关闭WebSocket，或配置.env+HTTP_PROXY让wss走代理，或启用ClashX/Stash的TUN模式彻底解决。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Mac电脑M1芯片运行Codex时反复显示“Reconnecting…1/5”、响应延迟高、首次提问卡顿1–2分钟，问题大概率出在WebSocket连接未正常走代理，而非账号异常或模型配置错误。
确认是否为本地环境问题
先排除Node与Codex本身未正确安装或版本过旧导致的底层失联。打开终端，依次执行：
node -v → 查看输出是否为 v18.17.0 或更高；若低于 v16.0，【必须升级Node】，旧版不支持M1原生NAPI模块，会强制回退到x86模拟层运行。
npm -v → 输出应大于 9.0；若报错“command not found”，说明npm未随Node正确安装，需重装Node（推荐使用nvm管理）。
codex --version → 必须能稳定返回版本号（如 v0.12.4）。若该命令偶发失败或超时，【说明CLI尚未在ARM64环境下稳定初始化】，此时任何网络配置优化都无效，必须先解决本地执行环境。
强制禁用WebSocket走代理
这是解决M1 Mac上Codex反复重连最直接有效的方法，适用于ClashX、Stash、Surge等主流代理工具未开启TUN模式或WebSocket分流规则缺失的场景。
方法一：通过命令行临时禁用
在终端中运行 codex --no-websocket start，启动后即可跳过所有reconnecting阶段，直连HTTPS接口。
方法二：永久写入配置文件
编辑 ~/.codex/config.toml，在[client]段落末尾新增一行：websocket = false；保存后重启Codex终端窗口。
注意：禁用WebSocket后，长上下文流式响应会变为分块返回，但对绝大多数编程问答、代码补全场景无感知影响。
配置.env让WebSocket正常走代理
若你依赖实时流式输出（如观察AI逐步思考过程），需确保wss协议也经代理转发。此方案要求代理软件支持WebSocket显式代理且已启用全局或规则模式。
第一步：确认代理监听地址与端口
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
打开ClashX或Surge界面，记下HTTP/S代理端口（如7890）和SOCKS5端口（如7891）；Codex默认只认HTTP_PROXY环境变量，不读SOCKS_PROXY。
第二步：创建并加载环境变量文件
在Codex项目根目录或~/.codex/下新建.env文件，写入：HTTP_PROXY=http://127.0.0.1:7890；HTTPS_PROXY=http://127.0.0.1:7890；NO_PROXY=localhost,127.0.0.1
第三步：启动时加载.env
cd到Codex所在目录 → 执行 source .env → 再运行 codex start；若使用VS Code终端，请关闭并重开终端使变量生效。
这一步操作起来很简单，直接把文件拖进去就行。但若.env路径放错位置（比如放在了Codex CLI安装目录而非运行目录），变量将完全不被读取，重连问题依旧存在。
开启代理软件TUN模式（仅限ClashX / Stash）
TUN模式可捕获系统级所有流量，包括WebSocket握手阶段的TCP连接，是M1 Mac上解决Codex重连最彻底的方案，尤其适用于代理规则复杂、域名分流不准的用户。
① 打开ClashX → 偏好设置 → 高级 → 勾选「启用TUN模式」；
② 点击右下角「允许」授予网络扩展权限（若弹窗未出现，前往「系统设置 → 隐私与安全性 → 网络扩展」手动开启）；
③ 返回ClashX主界面，点击「系统代理」开关，确保状态为ON；
④ 终端执行 codex start，不再出现reconnecting提示，且流式响应恢复原生体验。
⚠️ 注意：TUN模式启用后，部分企业防火墙或校园网策略可能拦截TUN设备，若启动失败或网络中断，请立即关闭该选项并切换回HTTP代理模式。
