codex连接超时首要排查本地环境：先在实际运行终端中执行node -v、npm -v、codex --version，若codex --version不稳定或报错，则问题出在node.js版本、path配置或终端环境隔离，此时修改api key或代理无效。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Codex连接超时确实和本地环境强相关，不是单纯改个API Key或换代理就能解决的问题。很多用户在Windows CMD里能跑通，切到Git Bash就报ETIMEDOUT；VS Code终端显示正常，系统PowerShell却卡死；甚至同一台机器上，用npm全局安装的Codex能连，npx临时调用就超时——这些现象背后都是本地环境变量、Node.js版本、终端继承机制、沙箱依赖等具体因素在起作用。
先确认本地基础命令是否稳定
打开终端，依次执行三行命令：
node -v → npm -v → codex --version
重点看codex --version是否每次都能秒出结果。如果输出不稳定、偶尔卡住、或提示“command not found”，说明本地环境本身就有问题。此时改任何配置都无效——Codex连启动都没完成，根本不会走到发HTTP请求那一步。
Windows用户特别注意：PowerShell中设置的$env:PATH不会自动同步到Git Bash，VS Code默认终端类型可能和系统终端不一致，【必须用Codex实际运行时所处的终端环境来测试】。
检查Codex进程是否继承了网络变量
第一步：在终端中设置代理变量（以Clash为例）
export HTTP_PROXY=http://127.0.0.1:7890 && export HTTPS_PROXY=http://127.0.0.1:7890
第二步：启动Codex CLI并获取其PID
codex suggest "hello" & pid=$! && sleep 2
第三步：读取该进程的真实环境变量
tr '\0' '\n'
如果输出为空，或只显示HTTP_PROXY=（等号后无值），说明Codex进程根本没有继承你设置的代理——它正在走系统直连。GUI应用、VS Code插件、WSL中由图形界面启动的进程，通常都不会读取shell的环境变量。
验证本地代理端口是否真正监听
方法一（Windows）：netstat -ano | findstr :7890
通过本地 Codex 或 OpenClaw OAuth 凭证直接调用 ChatGPT/Codex Responses 的 image_generation 工具来生成或编辑光栅图像，然后保存
方法二（macOS/Linux）：lsof -i :7890
只要输出中没有LISTEN状态，就说明代理工具根本没在监听该端口。常见原因是Clash/Surge未开启HTTP代理开关，或端口号被手动改过但config.toml里还写着旧端口。
方法三：直接curl测试链路
curl -x http://127.0.0.1:7890 https://api.openai.com/v1/models -I --max-time 5
返回HTTP/2 401或HTTP/2 200才算通；若提示Connection refused，说明代理服务压根没起来，或者监听地址不是127.0.0.1而是0.0.0.0——后者在某些安全策略下会被拦截。
排查bwrap沙箱是否卡死
第一步：运行超时检测命令
timeout 10 codex sandbox -- /bin/echo ok
第二步：观察返回值
如果返回124，说明沙箱启动失败。这不是网络问题，而是Linux下bubblewrap（bwrap）不可用。
第三步：定位bwrap来源
which bwrap && bwrap --version
如果命令卡住、无输出，或显示Conda路径下的一个132字节脚本，就证实是Conda环境污染了系统bwrap。此时需手动删掉Conda里的假bwrap，或把系统/usr/bin/bwrap加到PATH最前面。
