解决Codex思考时间长或长时间无响应

Gem
Gem
  • 6 次浏览

在中国网络环境下使用 Codex CLI 或类似 AI 命令行工具时，可能会遇到以下问题：

Reconnecting…
timeout waiting for child process to exit
长时间无响应

这些问题通常不是 Codex 本身异常，而是因为 CLI 进程无法稳定访问外网 API，导致请求超时、重连或卡住。

本文介绍一种比较干净、推荐的解决方式：

使用 ~/.codex/.env 文件，只为 Codex CLI 单独配置代理，不影响系统中的其他程序。

以下示例以 macOS 为主。Windows 端亲测也有效，只需要按照相同逻辑找到对应的 Codex 配置目录并写入环境变量即可。

一、核心思路

Codex CLI 启动时会读取以下文件：

~/.codex/.env

这个文件中的配置会作为环境变量注入到 Codex 进程中。

因此，我们可以通过 .env 文件实现：

  • 只让 Codex CLI 走代理
  • 不影响系统全局环境
  • 避免使用 export 带来的副作用
  • 方便后续修改和维护

简单来说：

.env 是给 Codex 单独准备的一份运行环境配置。

二、具体操作步骤

1. 找到或创建 .codex 目录

先进入用户目录：

cd ~

查看是否已经存在 .codex 目录：

ls -a | grep codex

如果存在，可以直接进入：

cd ~/.codex

如果不存在，则创建它：

mkdir -p ~/.codex
cd ~/.codex

2. 创建 .env 文件并写入代理配置

执行以下命令：

cat > ~/.codex/.env << EOF
HTTP_PROXY="http://127.0.0.1:7897"
HTTPS_PROXY="http://127.0.0.1:7897"
ALL_PROXY="socks5://127.0.0.1:7897"
EOF

其中 7897 是本地代理端口，需要根据你的代理软件实际端口进行修改。

例如，如果你的代理端口是 7890，就改成：

HTTP_PROXY="http://127.0.0.1:7890"
HTTPS_PROXY="http://127.0.0.1:7890"
ALL_PROXY="socks5://127.0.0.1:7890"

注意：

  • 端口必须和你的代理软件一致
  • 不要在等号两侧添加空格
  • 引号可以保留，避免特殊字符导致解析问题

3. 验证 .env 是否写入成功

执行：

cat ~/.codex/.env

正常情况下应输出类似内容：

HTTP_PROXY="http://127.0.0.1:7897"
HTTPS_PROXY="http://127.0.0.1:7897"
ALL_PROXY="socks5://127.0.0.1:7897"

如果内容为空，或者端口不正确，需要重新写入。

4. 清理旧的 Codex 进程

这一步很重要。

如果之前已经启动过 Codex，旧进程可能不会读取新的 .env 配置。可以执行：

pkill -f codex

或者直接重启 Codex 应用 / 终端会话。

这样可以避免旧 session 继续沿用未配置代理的环境。

5. 重新启动 Codex CLI

完成以上步骤后，重新运行：

codex

如果代理配置正确，Codex CLI 应该可以正常连接，不再频繁出现重连、超时或长时间无响应的问题。

三、原理说明

.env 文件本质上是一个环境变量配置文件，格式如下：

KEY=VALUE

Codex 启动时会自动加载这些变量。

这相当于你手动执行：

HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 codex

但使用 .env 的好处是配置更集中、更稳定，也不会污染整个终端环境。

对比一下两种方式：

方法影响范围是否推荐
export HTTP_PROXY=...当前终端或全局 shell 环境不推荐
~/.codex/.env仅 Codex CLI推荐

如果只是为了让 Codex 走代理，使用 .env 是更干净的方式。

四、常见问题

1. .env 不生效怎么办？

可以按顺序检查：

  1. 文件路径是否正确：
cat ~/.codex/.env
  1. 代理端口是否正确
    确认你的代理软件中 HTTP / SOCKS 端口是否真的是 7897。
  2. 旧进程是否已经清理：
pkill -f codex
  1. Codex 是否重新启动
    修改 .env 后，需要重新启动 Codex 才能读取新配置。

2. 如何判断是不是代理问题？

可以临时用命令行方式强制指定代理启动 Codex：

HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 codex

如果这样可以正常使用，但 .env 不生效，通常说明：

  • .env 文件路径不对
  • Codex 没有读取该文件
  • 旧进程没有被清理
  • 文件内容格式有误

3. HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 都需要写吗？

建议都写。

其中：

  • HTTP_PROXY：处理 HTTP 请求
  • HTTPS_PROXY：处理 HTTPS 请求
  • ALL_PROXY：作为更通用的代理兜底配置

不同工具或依赖库读取的环境变量可能不同，所以三个都配置可以提高兼容性。

五、总结

这种方法的本质是：

为 Codex CLI 构建一个独立的代理运行环境。

相比直接在终端里使用 export，通过 ~/.codex/.env 配置代理有几个明显优势：

  • 不污染系统环境
  • 不影响其他命令行工具
  • 配置集中，方便维护
  • 适合长期使用
  • 出问题时更容易排查

如果你在中国网络环境下使用 Codex CLI 时遇到：

Reconnecting…
timeout waiting for child process to exit
长时间无响应

可以优先尝试这种 .env 代理配置方式。