Codex CLI、OpenClaw、Hermes 共存避坑指南

这篇文章记录一次真实排障经验：同一台机器上同时运行 Codex CLI、OpenClaw、Hermes。三者都想使用 openai-codex，但如果处理不好，就会遇到两类常见问题：

• Hermes 提示 Codex refresh token 已经被其他客户端消费。
• OpenClaw 的 Telegram 已配对，但回复时提示缺少 OPENAI_API_KEY。

结论先说：可以使用同一个账号，但不要复制同一份 token。每个运行时都应该维护自己的登录态。

三者分别负责什么

简单理解：

• Codex CLI：你在终端里直接使用的 Codex。
• Hermes：一个独立 agent 运行时，有自己的配置、auth、session 和 gateway。
• OpenClaw：另一个独立 agent/gateway 运行时，可以接 Telegram、Feishu、Weixin 等渠道。

它们可以都使用 openai-codex，但它们不是同一个进程，也不应该共享同一个 refresh token 文件。

正确的登录方式

分别检查三边状态：

codex login status
hermes auth status openai-codex
openclaw config validate
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health

如果需要重新登录，分别走自己的命令：

# Codex CLI
codex login

# 远程或无浏览器机器
codex login --device-auth

# Hermes
hermes auth add openai-codex
hermes auth status openai-codex

# OpenClaw
openclaw models auth login --provider openai-codex
openclaw models status --json

不要这样做：

# 不要复制 Codex CLI 的 auth 文件给 Hermes 或 OpenClaw
cp ~/.codex/auth.json ~/.hermes/auth.json

也不要手工把 refresh token 从一个系统粘到另一个系统。

为什么不能共用同一个 refresh token

OAuth refresh token 往往会轮换。一个客户端用 refresh token 换取新 token 后，旧 token 可能立即失效。

如果 Codex CLI、Hermes、OpenClaw 同时拿着同一个 refresh token，就会出现这样的情况：

openai-codex: logged out
Codex refresh token was already consumed by another client

这不是网络问题，也不是模型问题。它表示：某个客户端已经使用并刷新了这份 token，另一个客户端手里的旧 token 失效了。

处理方式：

codex login
hermes auth add openai-codex
hermes auth status openai-codex

如果 OpenClaw 也失效，就单独重登：

openclaw models auth login --provider openai-codex

验证 Hermes 是否真的能用

配置存在不代表能跑。要做一次最小 smoke test：

NO_PROXY=127.0.0.1,localhost hermes chat -q "Reply exactly: ok"

看到返回：

ok

才说明 Hermes 的 openai-codex 真能完成一次模型调用。

OpenClaw Telegram 提示缺少 OPENAI_API_KEY 的原因

有时 Telegram 已经配对成功，但机器人回复：

Missing API key for OpenAI on the gateway. Use openai-codex/gpt-5.5, or set OPENAI_API_KEY, then try again.

这个错误通常不是 Telegram token 的问题，也不是配对问题。

真正原因往往是 OpenClaw 配置里把模型写成了：

"primary": "openai/gpt-5.5"

openai/gpt-5.5 会走 OpenAI API Key 路径，所以它要求 OPENAI_API_KEY。

如果你是用 Codex OAuth，就应该使用：

"primary": "openai-codex/gpt-5.5"

OpenClaw 推荐配置片段

打开：

nano ~/.openclaw/openclaw.json

检查 agents.defaults.model 和 agents.defaults.models：

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.5",
        "fallbacks": [
          "openai-codex/gpt-5.5-pro"
        ]
      },
      "models": {
        "openai-codex/gpt-5.5": {},
        "openai-codex/gpt-5.5-pro": {}
      }
    }
  }
}

如果你同时保留其他 provider，比如小米、OpenRouter，也可以保留它们；关键是默认链不要误写成 openai/*。

修改后必须验证

修改配置后：

openclaw config validate
systemctl --user restart openclaw-gateway.service
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health
openclaw models status --json

再做一次本地 agent 测试：

timeout 180 openclaw agent --local --agent main \
  --message '请只回复两个小写字母: ok' \
  --session-id smoke-openai-codex \
  --json --timeout 150

重点看输出里的：

{
  "provider": "openai-codex",
  "model": "gpt-5.5"
}

只要 provider 是 openai-codex，就说明它没有走 OPENAI_API_KEY 路径。

Telegram 的两个问题要分开看

Telegram 里可能同时出现两个现象：

You are not authorized to use this command.

和：

Missing API key for OpenAI on the gateway.

这不是同一个问题。

• not authorized：通常是命令权限、配对、allowlist 或管理命令权限问题。
• Missing API key：通常是模型 provider 写错，走到了 openai/*，而不是 openai-codex/*。

排障时不要把它们混成一个问题。

一张检查表

遇到 Codex CLI、OpenClaw、Hermes 共存问题时，按这个顺序查：

# 1. Codex CLI
codex login status

# 2. Hermes
hermes auth status openai-codex
NO_PROXY=127.0.0.1,localhost hermes chat -q "Reply exactly: ok"

# 3. OpenClaw 配置
openclaw config validate
openclaw models status --json

# 4. OpenClaw Gateway
systemctl --user is-active openclaw-gateway.service
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health

# 5. OpenClaw 本地模型调用
timeout 180 openclaw agent --local --agent main \
  --message '请只回复两个小写字母: ok' \
  --session-id smoke-openai-codex \
  --json --timeout 150

最重要的三条原则

第一，同账号可以，复制 token 不行。
Codex CLI、Hermes、OpenClaw 可以登录同一个账号，但不要共用同一份 refresh token。

第二，openai/* 和 openai-codex/* 不是一回事。
openai/* 通常走 API Key；openai-codex/* 才是 Codex OAuth 路径。

第三，配置正确不等于运行正确。
必须用 /health、hermes chat、openclaw agent --local 做实测，看到真的返回 ok，才算修好。