平台:macOS(Apple Silicon / Homebrew)· 版本:CLIProxyAPI 7.2.65
如果你手上有 ChatGPT/Codex 的订阅账号,却想在自己的脚本、IDE 插件或第三方工具里以「标准 OpenAI API」的方式调用它,CLIProxyAPI 就是干这件事的。它能把 Gemini CLI、Codex、Claude Code、Qwen Code 这类基于 OAuth 登录的 CLI 工具,统一包装成一个本地的、OpenAI 兼容的 HTTP 服务。
本文记录一次真实的安装与配置过程:从 brew install 到登录 Codex,再到起服务、验证,最后还踩了一个 Surge 代理拦截本地请求 的坑。
一、安装
1 | brew install cliproxyapi |
安装完成后,几个关键路径值得记一下(Apple Silicon 下的默认位置):
| 项目 | 路径 |
|---|---|
| 可执行文件 | /opt/homebrew/bin/cliproxyapi |
| 配置文件 | /opt/homebrew/etc/cliproxyapi.conf |
| 认证目录(存放 OAuth token) | ~/.cli-proxy-api |
| 默认监听端口 | 8317 |
看一下它支持哪些登录方式:
1 | cliproxyapi --help |
输出里能看到一堆 -xxx-login 选项,我们关心的是这两个:
1 | -codex-login Login to Codex using OAuth |
二、登录 Codex
这是整个流程的核心。直接运行:
1 | cliproxyapi -codex-login |
它会:
- 自动读取默认配置
/opt/homebrew/etc/cliproxyapi.conf,把 token 存到~/.cli-proxy-api; - 自动打开浏览器,跳转到 OpenAI/ChatGPT 的 OAuth 授权页(回调端口是 1455,确保没被占用);
- 你用 拥有 ChatGPT 付费订阅(Plus/Pro/Team)的账号 登录并授权;
- 授权成功后,token 落盘到认证目录。
登录成功后,你会在认证目录里看到一个以账号命名的 JSON 文件:
1 | $ ls -la ~/.cli-proxy-api |
没有图形界面 / 远程服务器? 改用设备码流程或禁止自动开浏览器:
1
2 cliproxyapi -codex-device-login # 设备码,在别的设备打开链接授权
cliproxyapi -codex-login -no-browser # 不自动开浏览器,自己复制链接
三、配置访问密钥
打开配置文件 /opt/homebrew/etc/cliproxyapi.conf,默认的 api-keys 是一组占位符:
1 | api-keys: |
这是客户端调用你这个代理时要携带的密钥(Bearer Token),和上面的 Codex 登录是两码事。建议换成你自己的一个强随机值。生成一个:
1 | echo "sk-$(openssl rand -hex 24)" |
然后把配置改成(只保留你需要的即可):
1 | api-keys: |
配置文件里其它值得留意的字段:
1 | port: 8317 # 监听端口 |
四、启动服务
用 Homebrew 的 services 管理,后台常驻 + 开机自启:
1 | brew services start cliproxyapi |
确认状态和端口:
1 | brew services list | grep cliproxy # 应显示 started |
如果只想临时前台运行、方便看日志,直接跑
cliproxyapi即可。
五、验证
服务地址是 http://127.0.0.1:8317/v1,接口是 OpenAI 兼容格式。
1. 列出模型
1 | KEY="sk-你的密钥" |
能返回一批模型(Codex 账号可用的 gpt-5.x 系列,如 gpt-5.5、gpt-5.4、gpt-5.4-mini、gpt-5.3-codex-spark、codex-auto-review 等)就说明 token 生效了。
2. 发一次真实对话(端到端验证)
1 | curl http://127.0.0.1:8317/v1/chat/completions \ |
拿到类似下面的响应(content: "ok"、usage 有计费),就彻底打通了:
1 | { |
六、踩坑:Surge(或其它系统代理)会拦截本地请求
第一次 curl 验证时,我拿到的不是 JSON,而是一个 Surge 的错误页:
1 | <h1>Connection Closed</h1> |
原因:系统里开着 Surge,curl 默认走了系统代理,发往 localhost:8317 的请求被 Surge 拦下并试图代理,结果失败。
临时绕过(命令行直连本地):
1 | curl --noproxy '*' http://127.0.0.1:8317/v1/models -H "Authorization: Bearer $KEY" |
长期解决(在 Surge 配置里让本地环回直连)——把这条规则放在 [Rule] 的靠前位置:
1 | [Rule] |
几点说明:
127.0.0.0/8是整个环回段(IANA 保留),全部直连安全,涵盖127.0.0.1;no-resolve表示匹配这条规则时不做 DNS 解析,只对 IP 字面量请求生效——正好对应我们用127.0.0.1直连的场景,还能避免为域名请求触发多余解析;- Surge 自上而下、首个命中生效,所以要放前面。
⚠️ 注意:因为加了
no-resolve,这条规则不匹配localhost这个主机名。如果你习惯用http://localhost:8317,再补一条:
1 DOMAIN,localhost,DIRECT
改完重载 Surge 配置后,curl 就不用再加 --noproxy '*' 了。
七、接入客户端
由于是 OpenAI 兼容接口,绝大多数支持自定义 base_url 的工具都能直接接:
1 | export OPENAI_API_KEY="sk-你的密钥" |
Python SDK 示例:
1 | from openai import OpenAI |
八、常用管理命令
1 | brew services restart cliproxyapi # 改配置后重启生效 |
小结
整套流程其实很短:
brew install cliproxyapicliproxyapi -codex-login登录 Codex- 改配置里的
api-keys brew services start cliproxyapi起服务curl验证
唯一容易卡住的地方,是本机开着 Surge 这类代理时,本地请求会被拦——一条 IP-CIDR,127.0.0.0/8,DIRECT,no-resolve 规则即可解决。之后,你就有了一个本地的、OpenAI 兼容的 Codex 网关,可以接到任何认 base_url 的工具里。