乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 给 Codex.app 装个遥控器

给 Codex.app 装个遥控器

当前时间： 2026-08-10 19:25:40 分类：办公文件 评论(0)
给 Codex.app 装个遥控器

最近我给 Codex.app 写了一个小命令：cx。

为什么要这么做？因为 Codex plus 额度太少了完全不够用，这时候要想继续用 codex 还不想提升额度只能使用中转站或者使用别的 coding plan 。

它的作用很简单。打开终端，输入 cx，选一个 Provider，然后 Codex.app 自动退出、重启，并带着新的配置跑起来。

听起来像一个很小的工具。但真正写起来，你会发现它刚好踩在几个常见问题上：GUI 应用到底读哪里配置？OAuth 登录和 API Key 怎么切？Bash 怎么安全地改 TOML？改完配置之后，怎样让正在运行的应用真的生效？

这篇文章就拆一下这个小工具。

起因：Provider 越多，手越忙

我最近同时在用几类东西：

  • • Claude Code 这种 CLI 工具
  • • Codex.app 这种 GUI 工具
  • • 一堆 OpenAI / Anthropic 兼容 Provider，比如 Fucheers、Z.AI、Kimi、DeepSeek、Qwen、MiniMax、Xiaomi MiMo

每个 Provider 都有自己的 Base URL、API Key、模型名。

如果手动切，通常要做三件事：

  • • 改 ~/.codex/config.toml
  • • 改 ~/.codex/auth.json
  • • 重启 Codex.app

最烦的是第三步。配置明明改了，但 Codex.app 没重启，于是它还在用旧配置。你以为是 Provider 坏了，结果只是应用没重新读文件。

我之前已经给 Claude Code 写过一个 cc 命令，用来切换 CLI 侧的 Provider。既然 CLI 可以切，那 GUI 为什么不行？

于是就有了 cx。

最终效果

现在终端里输入：

cx

会看到一个菜单：

Codex.app - Provider Selector
==============================
1) Codex Native (ChatGPT Login)  [default]
2) Fucheers Proxy  [key saved]
3) Zhipu Z.AI
4) MiniMax  [key saved]
5) Kimi / Moonshot  [key saved]
6) DeepSeek  [key saved]
7) Qwen (dashscope)
8) Xiaomi MiMo  [key saved]
9) Custom (manual input)

Select provider [1-9] (Enter for default = 1 Native):

直接回车，回到 ChatGPT 官方登录。输入数字，就切到对应 Provider。

选择完成后，脚本会做完配置修改，然后重启 Codex.app。对我来说，这就像给 Codex.app 装了一个遥控器。

第一步：先找到 GUI 的配置入口

想控制一个 GUI 应用，第一件事不是写脚本，而是找它到底读哪里。

Codex.app 主要看两个文件：

~/.codex/config.toml
~/.codex/auth.json

config.toml 管模型和 Provider：

model = "gpt-5.5"
model_provider = "Fucheers"

[model_providers.Fucheers]
name = "Fucheers"
base_url = "https://www.fucheers.top/v1"
wire_api = "responses"
requires_openai_auth = true

auth.json 管凭证。它有两种形态。

第一种是 ChatGPT OAuth 登录：

{
  "auth_mode": "chatgpt",
  "OPENAI_API_KEY": null,
  "tokens": {
    "id_token": "...",
    "access_token": "...",
    "refresh_token": "...",
    "account_id": "..."
  }
}

第二种是 API Key：

{
  "auth_mode": "apikey",
  "OPENAI_API_KEY": "sk-..."
}

这就是关键点：GUI 不靠你当前终端里的环境变量，它读的是这两个文件。

所以 cx 的核心逻辑其实很朴素：

  1. 1. 改 config.toml
  2. 2. 改 auth.json
  3. 3. 重启 Codex.app

第二步：用 alias 做入口

入口我没有做复杂，直接放到 shell 配置里：

alias cx="bash ~/codex-provider.sh"

我在 ~/.zshrc 和 ~/.bash_profile 都加了这行，因为有时候我在 iTerm 里用，有时候在其他终端里用。入口越简单，后面越不容易出问题。

脚本本体就是 ~/codex-provider.sh。

第三步：复用已有的 Provider Key

我之前给 cc 命令写过一套 Provider Key 管理，API Key 存在：

~/.claude-providers.keys

格式很直白：

fucheers=sk-xxx
kimi=sk-yyy
deepseek=sk-zzz

权限设成 600，只有自己能读写。

cx 直接复用这份文件。这样同一个 Provider 的 Key 不用在 Claude Code 和 Codex.app 里录两遍。

读 Key 的函数也很普通：

get_saved_key() {
  grep "^${1}=" "$KEYS_FILE" 2>/dev/null | cut -d'=' -f2-
}

保存 Key 时，我没有直接重定向覆盖原文件，而是先写临时文件，再 mv 回去：

save_key() {
  local provider_id="$1" key="$2"
  local tmp
  tmp=$(mktemp "${KEYS_FILE}.XXXXXX")

  grep -v "^${provider_id}=" "$KEYS_FILE" > "$tmp" 2>/dev/null || true
  echo "${provider_id}=${key}" >> "$tmp"

  mv "$tmp" "$KEYS_FILE"
  chmod 600 "$KEYS_FILE"
}

这样做的好处是，即使中途出错，也不太容易把原来的 Key 文件写坏。

第四步：菜单只是外壳，Provider 数据才是核心

Provider 信息我放在 Bash 数组里，每一项用 | 分隔：

declare -a PROVIDERS=(
  "native|Codex Native (ChatGPT Login)|||gpt-5.5|"
  "Fucheers|Fucheers Proxy|https://www.fucheers.top/v1|o1,o3,...|gpt-5.5|responses"
  "kimi|Kimi / Moonshot|https://api.moonshot.cn/v1|kimi-k2.6,...|kimi-k2.6|chat"
)

每一项包含这些字段：

Provider ID | 显示名 | Base URL | 模型列表 | 默认模型 | Wire API

菜单渲染时，如果本地已经保存了 Key，就显示 [key saved]。如果是 Native 登录，就显示 [default]。

用户选择完以后，脚本拿到这一项的 Provider ID、Base URL、默认模型和 Wire API，再进入真正的配置改写。

第五步：用 Python 帮 Bash 改 TOML

Bash 处理字符串很方便，但改 TOML 不太适合。

这里最危险的是：config.toml 里可能有很多地方都叫 model。我要改的是顶层的：

model = "gpt-5.5"
model_provider = "Fucheers"

不能误伤 section 里的同名字段：

[some.section]
model = "other-model"

所以我在 Bash 里嵌了一段 Python，做行级编辑。核心思路是：只在进入第一个 [section] 之前，修改顶层字段。

def set_top_level(key, value):
    in_section = False
    found = False
    out = []

    for ln in lines:
        if ln.lstrip().startswith("["):
            in_section = True
            out.append(ln)
            continue

        if not in_section and re.match(rf"^\s*{re.escape(key)}\s*=", ln):
            out.append(f'{key} = "{value}"')
            found = True
        else:
            out.append(ln)

    if not found:
        out.insert(0, f'{key} = "{value}"')

如果对应的 Provider 区块不存在，就追加到文件末尾：

header = f"[model_providers.{pid}]"
if not any(ln.strip() == header for ln in lines):
    lines += [
        "",
        header,
        f'name = "{pid}"',
        f'base_url = "{base_url}"',
        f'wire_api = "{wire_api}"',
        "requires_openai_auth = true",
    ]

每次改之前，脚本都会先备份：

~/.codex/config.toml.bak.<时间戳>

这类工具不追求一次写得多漂亮，先保证错了能退。

第六步：处理 auth.json

auth.json 比 config.toml 更微妙，因为它既可能是 OAuth 登录，也可能是 API Key。

切到 API Key 模式时，脚本直接写成：

{
  "auth_mode": "apikey",
  "OPENAI_API_KEY": "sk-..."
}

代码很短：

write_auth_apikey() {
  python3 - "$AUTH_JSON" "$1" <<'PY'
import sys, json
path, key = sys.argv[1], sys.argv[2]
with open(path, "w") as f:
    json.dump({"auth_mode": "apikey", "OPENAI_API_KEY": key}, f, indent=2)
PY
  chmod 600 "$AUTH_JSON"
}

切回 Native 登录就不能这么粗暴了。

OAuth token 不是你想生成就能生成的，它必须经过 GUI 登录流程。所以我做了一份 Native 快照：

~/.codex/auth.json.native-snapshot

第一次确认 Native 登录可用时，把当前的 auth.json 备份为快照。以后切回 Native，就把这份快照恢复回去。

restore_auth_native() {
  cp -p "$NATIVE_SNAPSHOT" "$AUTH_JSON"
  chmod 600 "$AUTH_JSON"
}

这一步的本质是把 OAuth 凭证当成“金种”保存起来。API Key 可以重新写，OAuth token 不要随便丢。

第七步：优雅重启 Codex.app

改完文件还不够。

Codex.app 如果正在运行，它不会自动重新读取配置。必须退出再启动。

我没有用 kill，而是用 macOS 的应用退出语义：

relaunch_app() {
  if pgrep -x "Codex" >/dev/null 2>&1; then
    echo "Codex.app 正在运行，退出以重载配置..."
    osascript -e 'tell application "Codex" to quit' 2>/dev/null

    for i in 1 2 3 4 5; do
      pgrep -x "Codex" >/dev/null 2>&1 || break
      sleep 1
    done
  fi

  open -a "Codex"
}

osascript 比 kill 温和。它相当于正常点“退出应用”，应用有机会保存自己的状态。

pgrep -x "Codex" 也很重要。不要只写 pgrep Codex，因为那可能匹配到各种 Helper 进程，导致脚本误判主应用还没退出。

踩过的几个坑

第一个坑，是我一开始以为 GUI 能靠环境变量控制。

CLI 里这样写很常见：

OPENAI_API_KEY=xxx codex -c model_provider=kimi

但 GUI 通过 open -a Codex 启动时，不继承你当前 shell 的这套环境变量。它拿到的是 macOS LaunchServices 提供的用户级环境。

所以这条路走不通。GUI 要切 Provider，还是得改它实际读取的配置文件。

第二个坑，是 Provider ID 的大小写。

config.toml 里可能是：

[model_providers.Fucheers]

但 Key 文件里是：

fucheers=sk-...

如果不做映射，就会出现两个 Provider 区块：Fucheers 和 fucheers。脚本能跑，但配置会越来越乱。

所以我加了一个转换函数：

resolve_key_id() {
  case "$1" in
    Fucheers) echo "fucheers" ;;
    *) echo "$1" ;;
  esac
}

第三个坑，是错误的 Key 留在 auth.json 里。

有一次我发现 auth.json 里写着某个代理 Provider 的 Key，但 config.toml 当前指向的是官方 OpenAI。结果 Codex.app 拿代理 Key 去请求官方接口，当然 401。

这类问题非常隐蔽，因为 GUI 只告诉你“认证失败”，不会告诉你“你拿错钥匙开错门了”。

所以我后来坚持两件事：

  • • 每次写配置前都备份
  • • Native OAuth 单独保存快照

小工具写到这里，已经不是“让它能用”了，而是“让它错了也好救”。

最后留下的文件

最后这套工具会涉及这些文件：

~/codex-provider.sh
~/.claude-providers.keys
~/.codex/config.toml
~/.codex/config.toml.bak.<时间戳>
~/.codex/auth.json
~/.codex/auth.json.bak.<时间戳>
~/.codex/auth.json.native-snapshot
~/.zshrc
~/.bash_profile

看起来不少，但边界很清楚：

  • • codex-provider.sh 是控制器
  • • claude-providers.keys 存 API Key
  • • config.toml 决定用哪个 Provider 和模型
  • • auth.json 决定用哪种凭证
  • • *.bak.* 负责回滚

这件事真正有用的地方

这个脚本本身不复杂。真正有用的是它提醒我：很多 GUI 工具并不神秘。

只要找到它读取的“事实之源”，也就是那些真正生效的配置文件，我们就可以在外层写一个很小的自动化，把重复动作包起来。

这类脚本有几个经验值得保留：

  1. 1. 先找配置源头，不要猜环境变量。
  2. 2. 凭证文件要谨慎，OAuth 和 API Key 分开处理。
  3. 3. Bash 不擅长的事情，就交给 Python 这样的小嵌入脚本。
  4. 4. 改配置前先备份，回滚能力比优雅写法更重要。
  5. 5. GUI 应用要正常退出，不要上来就 kill。
  6. 6. 每一步都打印进度，让脚本变得可观察。

写工具最舒服的地方，不是代码有多花哨，而是它把一个原本让人烦躁的动作压缩成一个命令。

以前切一次 Provider，要打开文件、检查 Key、保存、重启、再确认有没有生效。

现在就是：

cx

选一下，等 Codex.app 弹出来。

这就够了。