为什么要搞这个
自从 GPT-5.5 出来以后,我的开发重心开始从 Claude Code 逐渐转向 Codex 了。
倒不是说 Claude 不好用,而是 GPT-5.5 的开发能力确实已经不比 Claude Opus 差了,关键是性价比高很多。实际用下来,日常开发完全够用。
但问题来了。
我的 Mac 是老款 Intel 芯片的,Codex 客户端不支持。想用的话,只能走 CLI 或者编辑器插件。
我之前是找中转站凑合用的,但试了一段时间,要么感觉掺水严重很降智,要么不稳定。关键是感觉好烧钱。
况且我自己有 Codex 账号,为什么还要绕一圈用别人的中转?感觉自己的codex账号充了值好浪费就。
而且没有客户端的话,授权这块就很麻烦。CLI 和编辑器插件都需要 API 配置,但官方的授权流程又依赖客户端。
所以我就打算在自己电脑上搭个 CPA(CLIProxyAPI),直接用自己的 Codex 账号授权,然后 CLI 和编辑器都走这个代理。
这样既能用上 GPT-5.5,又不用担心中转站的问题。
什么是 CPA
CPA(CLIProxyAPI)是一个开源的 AI 接口代理工具,支持 Codex、Claude、Gemini 等多个平台的 OAuth 授权,可以把账号授权信息统一管理,然后通过标准的 OpenAI 兼容接口对外提供服务。
简单来说,就是在本地架一个中间层,让 CLI 和编辑器插件可以直接走自己的账号,不用再依赖第三方中转站了。
开源仓库:github.com/router-for-...
搭建方式
我看了下官方文档CLIProxyAPI 支持的部署方式挺多的,Linux、Windows、Mac 都有对应的方案。
由于我是 Mac 电脑,本来可以用 brew 安装,但我不太想用这种方式。一是不想在系统里装太多东西,二是 Docker 部署更干净,环境隔离也更好。
所以这里我选择用 Docker 部署。
如果其他同学是 Linux 或者 Windows,也可以直接参考官方文档的流程,应该会更简单一些。
顺便说一句:本文仅讨论如何管理个人合法持有的 AI 账号和 API Key,不涉及账号共享、售卖等违规行为。
搭建过程
官方文档给的 Docker 启动命令是这样的:
bash
docker run --rm -p 8317:8317 \
-v /path/to/your/config.yaml:/CLIProxyAPI/config.yaml \
-v /path/to/your/auth-dir:/root/.cli-proxy-api \
eceasy/cli-proxy-api:latest
这里有两个挂载点,一个是配置文件 config.yaml,一个是授权目录 auth-dir。
这里我们一定要挂载,因为如果不挂载的话,Docker 容器重启后,我们的授权配置就丢了,又得重新授权一遍。所以这里必须把配置和授权数据挂载到本地。
准备工作
首先,我在本地创建两个目录,用来存放配置文件和授权数据。
我的 Docker 相关文件都放在 /Users/kaka/Docker/ 下面,所以先创建两个目录:
bash
mkdir -p /Users/kaka/Docker/CLIProxyAPI/config
mkdir -p /Users/kaka/Docker/CLIProxyAPI/auth
然后我们需要获取一份官方的配置文件。这里我直接从 GitHub 下载:
bash
curl -o /Users/kaka/Docker/CLIProxyAPI/config/config.yaml \
https://raw.githubusercontent.com/router-for-me/CLIProxyAPI/main/config.example.yaml
这个命令是从 CPA 的开源仓库下载官方示例配置,并保存为 config.yaml。
这样准备工作就做好了,接下来就可以启动 Docker 容器了。
启动容器
这里我有个建议:尽量不要直接用 docker run 的形式去运行,特别是需要挂载的容器。
因为命令相对复杂,后续如果要做什么变更,还得删除容器、重启、重新 docker run,很麻烦。
我更推荐用 docker-compose.yml 的形式启动。这样后续做变更的时候,改一下配置文件,重新 docker compose up -d 就行了。
所以我在 /Users/kaka/Docker/CLIProxyAPI 下面新建了一个 docker-compose.yml,内容如下:
yaml
services:
cli-proxy:
image: eceasy/cli-proxy-api:latest
container_name: cli-proxy
ports:
- "8317:8317"
volumes:
- ./config/config.yaml:/CLIProxyAPI/config.yaml
- ./auth:/root/.cli-proxy-api
restart: always
然后在这个目录下运行:
docker compose up -d
Docker 会自动拉取最新镜像并启动容器。

因为我之前已经安装过了,所以直接就启动成功了。可以看到容器已经 Started。
启动成功后,可以查看一下日志,确认有没有报错:
docker logs cli-proxy

我这边直接成功了,没有报错。可以看到 CPA 服务已经在 8317 端口启动了。
这样,CPA 就通过 Docker 运行起来了。
配置 config.yaml
容器启动后,我们还需要简单配置一下 config.yaml 才能正常访问。
我们打开之前挂载的配置文件 /Users/kaka/Docker/CLIProxyAPI/config/config.yaml,这里需要改三个地方:

1. allow-remote: false 改为 true
yaml
allow-remote: true
因为我们是在 Docker 容器里运行 CPA 的,容器内部是一个独立的环境。如果不开启 allow-remote,宿主机(也就是我们的 Mac)就访问不了容器里的服务。
开启后,配合 secret-key 鉴权,既能让宿主机访问,也能保证安全。
2. secret-key: "" 设置一个密码
vbnet
secret-key: "123456"
这是后台登录密码,必须设置一个。我这里为了方便设置的是 123456,实际使用可以设置复杂一点的。
3. auth-dir: "~/.cli-proxy-api" 改为绝对路径
python
auth-dir: "/root/.cli-proxy-api"
这个要改是因为我们在 docker-compose.yml 里写的挂载路径是:
bash
- ./auth:/root/.cli-proxy-api
意思是把宿主机的 auth 文件夹,挂载到容器内的 /root/.cli-proxy-api。
在 Docker 环境里,程序运行在容器内部,默认的 ~ 路径可能识别不准确。我们直接写成绝对路径 /root/.cli-proxy-api,确保程序能准确读写授权文件。
如果是在 Windows 或 Linux 上直接运行(不用 Docker),保持默认的 ~ 就行,不用改。
改完这三个地方,保存配置文件,然后重启容器:
docker compose restart
这样配置就生效了。
配置 CPA
容器启动并配置好后,接下来就可以登录 CPA 后台进行配置了。
登录后台
在浏览器输入地址:
arduino
http://127.0.0.1:8317/management.html
回车后会跳转到 CPA 的登录页面。

输入我们在 config.yaml 里设置的密钥,我这里设置的是 123456,然后点击登录。

登录成功后,就可以看到 CPA 的管理后台了。左侧是功能菜单,包括仪表盘、配置面板、AI 提供商、认证文件、OAuth 登录等。
接下来我们就可以开始配置了。
认证配置
首先我们要配置 API 密钥,这个密钥后面在 cc switch 里配置的时候会用到。
打开左侧的配置面板,找到认证配置。

可以看到里面有三个密钥列表,这是 config.yaml 里初始化的默认密钥。
我建议把这三个默认密钥删掉,自己重新生成一个。因为默认密钥是公开的,不太安全。
删除后,点击右上角的"添加 API 密钥"按钮,然后选择生成。

生成后,可以看到新的密钥已经添加成功了。后续配置 cc switch 的时候,直接复制这个密钥就可以了。
注意:修改完配置后,一定要点击页面底部的"保存"按钮,否则配置不会生效。

网络配置
接下来需要配置代理,因为 Codex 登录是需要科学上网的哈。
具体操作办法大家自行找哈,这里我就不分享了。
我们需要找到该工具的端口号。
比如我这里科学上网工具的端口号是 7897,这个端口号后面配置代理时要用到。
然后回到 CPA 的管理后台,打开左侧的配置面板,找到网络配置。

在代理 URL这里填写:
arduino
http://host.docker.internal:7897

重点来了 :这里一定要用 http://host.docker.internal:7897,而不是 http://127.0.0.1:7897。
因为我们是在 Docker 容器里运行 CPA 的,容器内部的 127.0.0.1 指向的是容器自己,而不是宿主机。要访问宿主机的服务,必须用 host.docker.internal。
我之前根据大佬的教程配置的时候,就忘了自己是 Docker 部署,填写成 127.0.0.1 后就各种授权失败。折腾了好久才发现是这个问题。
所以这里一定要注意。
另外,我们还需要开启商业模式。
商业模式主要是为了安全。开启后,它会自动拦截上游模型的报错信息,防止我们的 API Key 泄漏;同时会开启最小化日志记录,保护聊天数据隐私;还会严格执行限流策略,防止接口被盗刷。
简单来说,就是给我们的 API 加一道安全锁。
配置完后,记得点击页面底部的保存按钮,然后重启 Docker 容器让配置生效:
docker compose restart
OAuth 授权
配置完网络后,接下来就是最关键的一步:OAuth 授权。
打开左侧的OAuth登录菜单。

可以看到这里支持多个平台的授权,包括 Codex、Anthropic、Antigravity、Gemini CLI 等。
我们这里选择 Codex,点击右侧的开始Codex登录按钮:

点击后会显示一个授权链接,我们直接点击打开链接或者复制链接到浏览器打开。

打开后会跳转到Codex的授权页面,这里我选择我的codex账号继续。

我们点击继续按钮进行授权。

授权成功后,会显示"Authentication successful!"的提示,窗口会在 5 秒后自动关闭。
这时候我们回到 CPA 后台,打开左侧的认证文件菜单。

可以看到已经有了 Codex 的认证文件,文件名是 codex-luokakale@gmail.com-free.json。
当然我们还可以到配额管理页面验证一下。打开左侧的配额管理菜单,找到Codex额度。

可以看到 Codex 的额度已经显示出来了,我这里因为这个账号我没续费所以是Free套餐,额度还没开始用所以是 100%。
这样,我们就成功授权了 Codex 账号,CPA 代理也就搭建成功了。
接下来就可以配置 CLI 了。
配置 cc switch
因为我开头说了,我喜欢在 CLI 和编辑器里面使用 Claude 和 Codex,所以我用的中转站很多。
为了方便管理这些中转站,我本地用的是 cc switch 来统一管理,非常好用。可以快速切换不同的 API 供应商。
现在我们把刚才搭建好的 CPA 添加到 cc switch 里。
打开 cc switch,切换到 Codex 标签页。

点击右上角的加号按钮,添加新供应商。

这里我们选择自定义配置。在这个页面,我们需要填写两个关键信息:
1. API Key
这个就是我们在 CPA 后台"认证配置"里生成的那个密钥,直接复制过来就行。
2. API 请求地址
填写:
arduino
http://127.0.0.1:8317/v1
填写完后,点击获取模型列表按钮,如果显示获取到n个模型的提示。就说明我们cpa连接成功了。

获取到模型列表后,我这里选择 gpt-5.5,因为这是目前最新的版本,开发能力最强。

然后往下滚动,找到"1M上下文窗口"选项。

勾选"1M 上下文窗口"。这样可以处理更长的上下文,对于大型项目开发很有用。
配置完后,点击右下角的"添加"按钮。
回到 cc switch 的列表页面,可以看到新添加的供应商已经出现在列表里了。
我们点击右侧的"测试模型"按钮,验证一下配置是否正确。

可以看到提示"洛卡卡了运行正常",说明我们配置成功了。
这样,cc switch 的配置就完成了。接下来就可以在 CLI 和编辑器里正常使用了。
验证
最后,我们验证一下配置是否真的生效了。
打开终端,输入 codex 进入 Codex CLI。

我们随便输入一句话测试一下,可以看到 Codex 正常回复了,说明配置成功了。这样,CPA 结合 cc switch 的配置就全部完成了。现在我们可以在 CLI 和编辑器里正常使用自己的 Codex 账号了。
踩坑记录
最后说说我在配置过程中遇到的最大的坑。
初次配置的时候,我在 OAuth 授权这一步一直失败,报错提示是:
less
认证失败:Failed to exchange authorization code for tokens
反复折腾了很久,授权链接能打开,账号也能选择,但就是最后一步交换 token 的时候失败。
我去L站搜了相关的问题,看到有人遇到类似的情况,总结下来就是代理的问题。
但我对比大佬给的解决方案,并没有看出来自己哪里配置不对。代理开了,端口也对,魔法工具也在正常运行的。
最后在重头梳理复盘的时候,我才发现问题出在哪里:
因为我是 Docker 部署的,代理 URL 那里填写的是 http://127.0.0.1:7897。
在 Docker 容器里,127.0.0.1 指向的是容器自己,而不是宿主机。所以授权的时候,容器根本访问不到宿主机上的魔法工具,自然就无法走魔法,导致一直失败。
解决方案就是把代理 URL 改成:
arduino
http://host.docker.internal:7897
改完后,重启容器,再次授权,就成功了。
另外,也有人说需要开启魔法工具的网络代理模式。我这里没开也成功了,不过也算是标记一下,如果有其他同学遇到类似问题,可以试试哈。