【求助】codex要使用antigravity-tool做反代如何配置

[mingliao]

感谢作者的辛勤付出，请教下。
我使用cc-Switch 按照如下配置

{
  "OPENAI_API_KEY": "sk-xxx", 
  "last_refresh": "2026-01-07T07:50:55.549601Z",
  "tokens": {
    "access_token": "xxx1",
    "account_id": "xxx2",
    "id_token": "xxx3",
    "refresh_token": "xxx4"
  }
}

其中 OPENAI_API_KEY 就是antigravity-tool提供的key
api请求地址 配置的是 http://127.0.0.1:8045/v1
模型名称 配置的是 gemini-3-flash
这样的配置，在codex-cli工具一直提示401未授权，是工具不支持codex-cli么？

新手不太懂，查了很多文档，也没看出个所以然来，有了解的大佬帮忙看下解答下，感谢。

[Vucius]

以下内容 仅供参考:
结论先说：Codex 官方文档明确支持把自己指向「任意 OpenAI 风格的代理/网关」，所以只要 Antigravity-Manager 的 API Proxy 能兼容 OpenAI/Claude/Gemini 的 HTTP 协议和鉴权方式，就可以像对 Cursor 一样，用在 Codex 上。[1][2]

文档里跟「反代」直接相关的点

• Codex 有「自定义模型提供方（Custom model providers）」的配置项，可以配置一个 provider 的 base_url、「线上的 API 协议（wire API）」以及额外 HTTP 头等。[1]
• 文档里还专门说：如果只是想把内置的 OpenAI 提供方指向一个 LLM proxy/router，可以设置环境变量 OPENAI_BASE_URL，这样 Codex 会把对 OpenAI 的请求发到你指定的地址，而不是默认的 https://api.openai.com。[1]
• 第三方教程也直接用这一点，把 Codex 指向 LiteLLM 这类本地/远端代理服务，比如：

  export OPENAI_BASE_URL=http://localhost:4000
  codex

  在这个例子里，localhost:4000 就是一个「OpenAI 协议的反代/网关」。[2]

这些能力和你描述的 Antigravity-Manager API Proxy 完全吻合：它在本地起一个 Web 服务器，伪装成 OpenAI/Claude/Gemini 官方 API，然后再转发到 Google 内部接口，本质就是一个更智能的 OpenAI 兼容反代。

对应到 Antigravity-Manager API Proxy 的使用方式

只要 Antigravity 这层对外暴露的是「OpenAI 兼容」接口（路径类似 /v1/chat/completions、/v1/responses，鉴权用 Authorization: Bearer ... 之类），那 Codex 侧可以有两种典型接入方式：[3][2][1]

1. 简单模式：直接覆写 OpenAI 基础地址

   • 启动前设置：

     export OPENAI_BASE_URL="http://localhost:8045"   # Antigravity 本地服务
     export OPENAI_API_KEY="你的 Antigravity / OpenAI 侧 key"
     codex

   • 对 Codex 来说，它以为在访问 OpenAI，其实所有请求都被发到了 Antigravity 的代理入口。[2][1]

2. 进阶模式：写一个单独的 provider

   • 在 ~/.codex/config.toml 里加一个自定义 provider，例如：

     [model_providers.antigravity]
     name = "antigravity"
     base_url = "http://localhost:8045"
     wire_api = "responses"        # 按 Antigravity 兼容的协议类型来填
     env_key = "OPENAI_API_KEY"    # 或者自定义 env 名

   • 然后用：

     export OPENAI_API_KEY="你的 key"
     codex --provider antigravity

   • 这样就显式地告诉 Codex：走这个名叫 antigravity 的代理提供方。[4][3][1]

文档和实践案例都说明：Codex 可以把后端完全换成第三方的「OpenAI 协议代理服务」，包括本地、远端，甚至像 XAI Control、LiteLLM 这种多路复用网关。[4][2][1]

和你现在的情况对应起来

• 你已经在 Cursor Code 上用 Antigravity-Manager 的 API Proxy，说明它对外暴露的是 OpenAI/Claude/Gemini 兼容的 HTTP API。
• Codex CLI 本身支持：
  • 指定 OPENAI_BASE_URL 指向一个 LLM proxy（官方原话就是 “point the built-in OpenAI provider at an LLM proxy or router”）。[1]
  • 在配置文件里自定义新的 provider，设置 base_url 到任何兼容的网关。[3][1]

所以，从文档和例子看，Antigravity-Manager 的 API Proxy 可以用在 Codex 上，和用在 Cursor Code 上是同一类玩法；配置上只需要把 Codex 的 OpenAI base URL / provider base_url 改成 localhost:8045（或你实际的监听地址），再配好对应的 key/headers 即可。[2][1]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[wickedmc4ever]

tip: a similar argument exists: '--local-provider'
codex version ：0.84.0

[mingliao]

tip: a similar argument exists: '--local-provider' codex version ：0.84.0

老哥，你解决了么，哈哈，我研究了很久，基本上各种查，还是不行。

[QianChenJun]

加一，ccs配置如下：

{ "error": { "code": 400, "message": "{\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\": \"tools.5.custom.input_schema: Field required\"},\"request_id\":\"req_vrtx_011CXJR5hE2QcKWgy8SKVAZ1\"}", "status": "INVALID_ARGUMENT" } }

[Catsler]

🎯 解决方案：使用独立的环境变量名

为每个第三方供应商使用专属的环境变量名，与官方 OpenAI 认证完全隔离。

1. 设置第三方 API 环境变量

为 antigravity 供应商设置专用环境变量（不要用 OPENAI_API_KEY）

echo 'export ANTIGRAVITY_API_KEY="sk-xxxxxxxxxxxxxxx' （你反代的api key）>>
~/.zshrc
source ~/.zshrc

2. 修改 config.toml

[model_providers.antigravity]
name = "antigravity"
base_url = "http://127.0.0.1:8045/v1"
wire_api = "responses"
env_key = "ANTIGRAVITY_API_KEY" # ← 使用专用变量名，不是 OPENAI_API_KEY
requires_openai_auth = false

3. auth.json 保持官方用途

{
// 这里只存储官方 OpenAI OAuth tokens
// 第三方 API keys 通过环境变量管理
}

---

📊 多供应商配置示例

官方 OpenAI（使用 auth.json 中的 OAuth）

[model_providers.openai]
requires_openai_auth = true # ← 使用官方授权

第三方 Antigravity（使用独立环境变量）

[model_providers.antigravity]
name = "antigravity"
base_url = "http://127.0.0.1:8045/v1"
wire_api = "chat"
env_key = "ANTIGRAVITY_API_KEY" # ← 专用变量
requires_openai_auth = false

另一个第三方供应商（如果有）

[model_providers.another_provider]
name = "another"
base_url = "http://xxx.xxx.xxx/v1"
wire_api = "chat"
env_key = "ANOTHER_API_KEY" # ← 另一个专用变量
requires_openai_auth = false

---

🔄 切换逻辑
┌────────────┬────────────────┬──────────────────────────────────────────────┐
│ 供应商类型 │ 认证方式 │ 配置 │
├────────────┼────────────────┼──────────────────────────────────────────────┤
│ 官方 │ auth.json │ requires_openai_auth = true │
│ OpenAI │ (OAuth) │ │
├────────────┼────────────────┼──────────────────────────────────────────────┤
│ 第三方 API │ 环境变量 │ env_key = "XXX_API_KEY" + │
│ │ │ requires_openai_auth = false │
└────────────┴────────────────┴──────────────────────────────────────────────┘

⚡ cc-switch 修复建议

向 cc-switch 作者反馈，建议修改生成逻辑：

当 requires_openai_auth = false 时:
- env_key 应该生成为 "{PROVIDER_NAME}_API_KEY"（如 "ANTIGRAVITY_API_KEY"）
- 同时提示用户设置对应的环境变量
- 不应该把 API key 值写入 env_key 字段

这样官方授权和第三方 API 就完全独立，互不影响。