Codex Mobile 远程控制桌面端的另一种玩法

实战教程

通过修改配置文件，让 Codex 的 Auth 层继续走 ChatGPT 账号保留 Mobile 权限，Model 层悄悄换成第三方 API，实现免费账号也能用手机远程控制桌面端 Codex。

Codex Mobile 远程控制桌面端的另一种玩法

ChatGPT 官方在 5 月中旬给 Codex 加了个新功能：手机端可以远程控制桌面端应用。这个功能本身挺实用，开发者不用一直守在电脑前，手机上就能审批任务、查看进度。但问题是，官方把这个功能绑定在了 ChatGPT 账号登录上，而且实际对话请求会直接打到 OpenAI 官方接口。

对于习惯用第三方 API 的开发者来说，这就有点尴尬了。要么放弃 Mobile 远程控制，要么放弃自己的 API 配置。最近 Linux.do 上有人摸清了 Codex 的内部架构，找到了一个折中方案：让 Auth 层继续认 ChatGPT 账号，保留 Mobile 功能，Model 层悄悄换成第三方 API。

Codex 的两层架构

要理解这个方案，得先搞清楚 Codex 内部是怎么工作的。它的架构分了两层：

Auth 层：负责登录状态、Plus 会员验证、插件权限、Mobile 解锁、额度查询。这一层认的是你的 ChatGPT 账号，跟 OpenAI 官方服务器通信。

Model 层：负责实际的对话请求，把你输入的内容送到某个模型，拿回来回复。这一层认的是 config.toml 里配置的 provider，可以是 OpenAI 官方，也可以是任何兼容 OpenAI API 格式的第三方服务。

这两层目前是解耦的。Auth 层验证完你的身份和权限后，Model 层并不关心你用的是哪个账号，只管按配置文件里的 API 地址发请求。这就给了我们操作空间。

Codex 架构示意图，左侧 Auth 层连接 ChatGPT 账号，右侧 Model 层连接第三方 API

为什么要这么折腾

直接用 ChatGPT 账号登录 Codex 不就行了？对于很多开发者来说，还真不行。

首先是成本。OpenAI 官方 API 的定价对于高频使用场景来说并不便宜，尤其是 GPT-4 系列。第三方 API 聚合平台（比如 OpenAI Hub）通常能拿到更低的价格，而且一个 Key 可以调用多家模型，切换灵活。

其次是网络。国内直连 OpenAI 官方接口需要特殊网络环境，稳定性也是个问题。第三方平台通常提供国内直连节点，延迟更低，更稳定。

再就是额度管理。很多团队用的是企业账号，API Key 统一管理，额度分配更灵活。如果每个开发者都用自己的 ChatGPT 账号登录 Codex，额度就没法统一控制了。

但 Mobile 远程控制这个功能确实有用。尤其是跑长时间任务的时候，能随时用手机看看进度、批准下一步操作，比一直守在电脑前舒服多了。所以才有了这个「Auth 层走官方，Model 层走第三方」的折中方案。

具体怎么操作

准备工作

你需要：

  1. 一个 ChatGPT 账号，免费的就行。因为 Mobile 远程控制功能对所有登录用户开放，不需要 Plus。
  2. 一个支持 OpenAI Responses API 的第三方平台账号。注意，必须支持 /v1/responses 端点，这是 Codex 用的新格式，不是传统的 /v1/chat/completions。
  3. 找到 Codex 的两个配置文件：~/.codex/auth.json 和 ~/.codex/config.toml。

关于第三方平台的选择，目前支持 Responses API 的平台还不算多。OpenAI Hub 是其中一个，完整适配了 Codex 的新格式。其他一些老牌中转平台可能还没跟进，用之前最好确认一下。

第一步：先登录 ChatGPT 账号

这一步的顺序很关键。在修改任何配置文件之前，先在 Codex 里正常完成 ChatGPT 账号登录，保持登录态。

为什么要先登录？因为 Codex 在登录过程中会写入一些 Auth 相关的 token 和状态信息到 auth.json。如果你先改配置再登录，Auth 层会因为配置不一致出问题，可能导致登录失败或者 Mobile 功能无法激活。

登录完成后，你应该能在桌面端 Codex 里看到你的 ChatGPT 账号信息，Mobile 功能也应该是可用状态。这时候再去改配置文件。

第二步：修改 auth.json

找到文件 ~/.codex/auth.json，用任意文本编辑器打开。这个文件是 JSON 格式，里面存了你的登录状态、token、API Key 等信息。

找到这两个字段，改成如下值：

{
  "auth_mode": "chatgpt",
  "OPENAI_API_KEY": null
}

其他字段一律不动。

auth_mode 改为 "chatgpt" 表示登录验证继续走 ChatGPT 账号。这样 Auth 层会继续认你的 ChatGPT 登录状态，Mobile 功能、插件权限这些都保留。

OPENAI_API_KEY 设为 null 表示不使用官方 API Key。这一步很重要，如果这里还留着一个有效的 OpenAI API Key，Codex 可能会优先用它去调用官方接口，而不是走你后面配置的第三方 provider。

保存文件。

第三步：修改 config.toml

找到文件 ~/.codex/config.toml，在文件末尾追加以下内容：

[model_providers.custom]
name = "custom"
base_url = "https://your-api-endpoint.com"
wire_api = "responses"
experimental_bearer_token = "your-api-key-here"

这里配置的是 Model 层要用的 provider。

  • name：给这个 provider 起个名字，随便写，比如 "custom" 或者 "openai-hub"。
  • base_url：第三方 API 的地址。比如 OpenAI Hub 的地址是 https://api.openai-hub.com。
  • wire_api：必须设为 "responses"，这是 Codex 用的新格式。
  • experimental_bearer_token：你的 API Key。

保存文件。

然后在 Codex 的设置里，把默认 provider 切换到你刚配置的这个 custom。具体路径是 Settings → Model Providers → Default Provider。

第四步：重启 Codex

配置文件改完后，重启 Codex 让配置生效。

重启后，你应该能看到：

  1. 桌面端 Codex 还是显示你的 ChatGPT 账号登录状态。
  2. 发起对话时，实际请求会打到你配置的第三方 API 地址。
  3. 手机端 ChatGPT 应用里，Codex 的远程控制功能依然可用。

这时候你就实现了「Auth 层走官方，Model 层走第三方」的效果。

手机端 ChatGPT 应用中 Codex 远程控制界面截图

验证是否生效

怎么确认配置真的生效了，Model 层确实在用第三方 API？

最直接的方法是看第三方平台的用量统计。在 Codex 里发起几轮对话，然后去你的第三方平台后台查看 API 调用记录。如果能看到对应的请求，说明配置成功了。

另一个方法是看延迟。如果你用的第三方平台有国内节点，延迟应该会比直连 OpenAI 官方低不少。可以在 Codex 的开发者工具里看请求的响应时间。

还有一个细节：如果你配置的第三方平台支持多个模型（比如 OpenAI Hub 同时支持 GPT、Claude、Gemini），你可以在 Codex 里切换模型试试。如果能正常切换并且都能用，说明 Model 层确实在走你配置的 provider。

可能遇到的问题

Mobile 功能失效

如果按上面的步骤操作后，Mobile 远程控制功能不可用了，大概率是 auth.json 里的 auth_mode 没改对，或者改配置之前没有先登录 ChatGPT 账号。

解决方法：把 auth.json 和 config.toml 都恢复成默认状态，重新在 Codex 里登录 ChatGPT 账号，确认 Mobile 功能可用后，再按步骤重新修改配置文件。

对话请求还是打到 OpenAI 官方

如果发现对话请求还是打到 OpenAI 官方接口，没有走第三方 API，检查这几个地方：

  1. auth.json 里的 OPENAI_API_KEY 是不是设成了 null。如果这里还有一个有效的 Key，Codex 会优先用它。
  2. config.toml 里的 base_url 是不是填对了。注意不要多加或少加斜杠。
  3. Codex 的设置里，默认 provider 是不是切换到了你配置的那个。

第三方 API 返回错误

如果 Codex 能正常发起请求，但第三方 API 返回错误，可能是：

  1. API Key 填错了或者过期了。
  2. 第三方平台不支持 Responses API 格式。确认一下平台文档，看是否支持 /v1/responses 端点。
  3. 第三方平台的某些模型不支持 Codex 用的某些参数（比如 streaming、function calling）。可以换个模型试试。

这个方案的局限性

这个方案虽然能用,但也有一些局限:

首先,它依赖 Codex 当前的架构设计。如果 OpenAI 后续更新把 Auth 层和 Model 层强绑定,这个方案可能就失效了。

其次,插件功能可能会有问题。Codex 的一些插件(比如 Web Search、DALL-E)是直接调用 OpenAI 官方服务的,如果你的第三方 API 不支持这些功能,插件就用不了。

再就是模型能力的差异。即使第三方平台支持 GPT-4,它的实际表现也可能跟 OpenAI 官方有细微差别,因为中间多了一层转发。对于要求极高的场景,这个差异可能会影响体验。

最后,这个方案本质上是在利用 Codex 架构的一个「特性」,算不上官方支持的用法。如果出了问题,OpenAI 的技术支持大概率不会管。

值得这么折腾吗

对于个人开发者来说,如果你本来就在用第三方 API,而且确实需要 Mobile 远程控制功能,这个方案值得一试。配置过程不复杂,十分钟就能搞定,后续也不需要额外维护。

对于团队来说,如果有统一的 API Key 管理需求,或者对成本比较敏感,这个方案也有价值。尤其是那些已经在用 OpenAI Hub 这类聚合平台的团队,切换成本很低。

但如果你对稳定性要求极高,或者重度依赖 Codex 的插件功能,还是老老实实用官方账号登录比较稳妥。毕竟这个方案不是官方支持的,出了问题只能自己解决。

写在最后

这个方案的出现,本质上反映了开发者对灵活性的需求。Codex 作为一个开发工具,用户群体本身就是技术人员,他们有能力也有意愿去定制自己的工作流。OpenAI 把 Mobile 功能绑定在官方账号上,可能是出于安全或商业考虑,但对于习惯用第三方 API 的开发者来说,这确实带来了不便。

好在 Codex 的架构设计给了我们操作空间。Auth 层和 Model 层的解耦,让我们可以在保留官方功能的同时,使用自己选择的 API 服务。这种灵活性,正是开源精神和开发者文化的体现。

当然,这个方案能用多久,取决于 OpenAI 后续的产品策略。如果他们决定把架构改得更封闭,这个方案可能就失效了。但至少在当下,它为开发者提供了一个可行的选择。

如果你也在用 Codex,也在用第三方 API,不妨试试这个方案。配置过程不复杂,效果也不错。即使后续 OpenAI 改了架构,大不了再切回官方登录,也没什么损失。

参考来源