当AI工具自身出问题时，不妨让它自己诊断自己。本文作者通过让ChatGPT分析截图、日志与代理配置，成功解决了Codex远程控制的连接故障。这不仅是一次技术排障，更展示了人机协作的新模式：人提供现场，AI持续推理，共同逼近根因。

先说结论：AI 不只是帮你”用工具”，当它越来越深入你的操作系统、开发环境和产品生态，它也开始具备一种很有意思的能力——诊断自己的工具链。

我一直想把手机上的 ChatGPT 和 Mac 上的 Codex 连接起来。

这样，作为负责我产品研发的数字员工，电脑上的 Codex 可以继续干活；我离开电脑以后，仍能用手机查看任务进度、继续发指令，甚至直接推进正在进行的开发工作。

但这个远程控制功能，我之前折腾过好几次，一直没有成功。

我自己查过资料，也问过豆包，反复试过登录、配对、重启、更新客户端、检查账号和工作空间。可最后每次都卡在同一个地方——Mac 上点击「允许」后，马上出现一行红字：无法启用远程控制，请重试。

折腾几次以后，我一度以为可能是账号权限、版本限制，或者这个功能在我的网络环境下就是用不了。

直到今天，我突然灵机一动：既然出问题的是 ChatGPT/Codex，那为什么不让 ChatGPT 自己来解决自己的问题？

一句“连接起来”，开启一段人机协作排障之旅

于是，我把手机端和桌面端的实际界面一张张截图发给 ChatGPT，只说了一句：

“把我的这个桌面端和我的手机端连接起来。”

没想到，这句话开启了一段挺有意思的排障之旅。

我负责点按钮、截图、执行命令；ChatGPT 负责看截图、分析现象、查官方文档、给排查命令、读日志、提出假设，并根据每一次结果不断修正判断。

这不是一次就答对的过程。中间也走过弯路，也有判断被新的证据推翻。但和以前最大的不同是：这次不是”问一个问题，得到一个答案”，而是让 AI 持续参与整个问题解决过程。

AI 没有因为前面的判断失败，就停在一个似是而非的答案上。它持续利用新的现场信息修正判断，最终把我们逼到了真正的根因。

不是账号，不是手机，也不是版本——是“代理”

最终，我们把一个之前一直解决不了的问题，定位到了一个很隐蔽的地方：

• 不是账号
• 不是手机
• 不是工作空间
• 不是 Codex 版本
• 甚至不是简单的“有没有代理”

真正的问题是：Codex Remote Control 的后台连接，没有正确继承我 Mac 上正在使用的代理环境。

下面，我把整个过程完整记录下来。也许能帮到同样卡在这里的人。

先理清：我要的不是普通的多端聊天同步

我的目标是：Mac 运行 Codex → 手机 ChatGPT 连接这台 Mac → 手机上继续操作正在工作的 Codex。

例如，我在 Mac 上让 Codex 修改项目代码、跑测试、分析 Bug，或者执行一个耗时的开发任务；随后离开电脑，手机依然能查看任务、追加指令、继续推进后续工作。

对于经常用 Codex 做开发的人来说，这个能力很有价值。真正令人沮丧的是：功能入口明明就在眼前，我却始终连不上。

先从手机端开始：配对和工作空间并不是问题

手机 ChatGPT 中有 Remote Control 的入口，大致流程是：设置 → 远程控制 → 添加连接 → 配对新设备。

手机会提示使用同一个账号登录桌面应用，并确认桌面端使用的是同一个工作空间，然后从桌面端获取配对信息。

这里有一个很容易误解的点：“同一个工作空间”不是指 Codex 里的代码项目，而是 ChatGPT 的 Workspace。

例如个人工作空间、Business 工作空间或 Enterprise 工作空间。我的手机和 Mac 使用的是同一个 ChatGPT 账号，也都在个人工作空间中，因此这条线索很快被排除了。

真正卡住我的，是 Mac 上的一句红字

问题出在 Mac 端。进入：设置 → 连接 → 控制这台 Mac。

点击「允许」，正常情况下应该进入配对流程；但我的桌面端每次都会直接提示：

“无法启用远程控制。请重试”

重启不行，退出重新登录不行，手机重新配对也不行，反复点「允许」仍然不行。

这时候最容易怀疑的是账号权限，或者个人 Workspace 不支持。但继续排查后发现，这两个方向都不成立。

先升级 Codex：版本也不是根因

排查过程中发现桌面版刚好有更新。我的旧版本是26.803.61601，可升级到26.810.50856。

我直接升级，原以为这可能只是旧版本的 Bug。升级完成后，再次进入「设置 → 连接 → 控制这台 Mac → 允许」。

结果依然是那句熟悉的红字：无法启用远程控制，请重试。

到这里，可以基本排除简单的客户端版本问题。

真正有用的一步：直接看官方日志

常规操作都没有答案后，我们转而查看 Codex 官方说明中提供的 macOS App 日志位置：

日志路径

~/Library/Logs/com.openai.codex/YYYY/MM/DD

在日志中搜索 Remote Control 相关内容，发现了几组关键信息：

关键日志

method=remoteControl/enable errorCode=null refresh_remote_control_started refresh_remote_control_completed nextConnectionCount=0 previousConnectionCount=0 creationFailureCount=0

这组日志很值得琢磨。remoteControl/enable 并没有直接报错，errorCode 也是 null；Remote Control 模块看起来已经启动，创建失败次数也不是问题。但它始终无法建立连接，ConnectionCount 一直停在 0。

这意味着：问题不太像出在开关本身，更可能在更底层的连接路径上。于是，我们把注意力转向了网络。

检查系统代理：Codex 能联网，不代表 Remote Control 也能联网

我的 Mac 有一个关键前提：访问 ChatGPT 需要经过本机代理。

通过查看系统代理配置，确认当时的本地代理为：

本机代理（示例端口，因人而异）

HTTP → 127.0.0.1:33210 HTTPS → 127.0.0.1:33210 SOCKS → 127.0.0.1:33211

它们都处于启用状态。这也解释了一个很有迷惑性的现象：ChatGPT 能正常使用，Codex 也能正常写代码，所以直觉上很容易认为网络肯定没有问题。

但一个桌面应用内部可能不止一条网络链路。主程序能正确使用系统代理，不代表它启动的每个后台连接都一定会继承同样的代理设置。

于是，我们做了两个简单而关键的对照实验。

实验一：不指定代理，直接访问 ChatGPT

curl 直连（超时）curl -I –connect-timeout 10 https://chatgpt.com # 结果 Failed to connect to chatgpt.com port 443 Timeout was reached

也就是说，不经过代理，终端根本无法访问 ChatGPT。

实验二：明确指定本机 HTTP 代理

curl 走代理（建立连接）curl -I –proxy http://127.0.0.1:33210 –connect-timeout 10 https://chatgpt.com # 结果 HTTP/1.1 200 Connection established

这次很快出现HTTP/1.1 200 Connection established。后面即使出现 Cloudflare 的 HTTP 403，也不是重点——关键在于：HTTPS 隧道已经成功建立。

两个结果放在一起，事情就清楚了：直连超时；显式走代理后立即建立连接。结合前面的日志，我们得到一个很强的判断——Codex Remote Control 的后台连接很可能没有正确走系统代理。

最后的验证：给 Codex 显式注入代理环境变量

接下来做的是一个可撤销的验证，而不是直接修改系统设置。

先完全退出 Codex（⌘Q），再在终端执行：

显式注入代理后启动 Codexexport HTTP_PROXY=http://127.0.0.1:33210 export HTTPS_PROXY=http://127.0.0.1:33210 export ALL_PROXY=socks5://127.0.0.1:33211 open -a “Codex”

注意：33210 和 33211 是我本机代理软件使用的端口，并不代表你的代理端口也是这两个。请根据自己的实际配置修改。

这样启动 Codex 后，再回到「设置 → 连接 → 控制这台 Mac → 允许」。

这一次，成功了。手机终于连接上了 Mac 上的 Codex。

根因验证清楚：系统代理本身正常，ChatGPT/Codex 主程序也能使用；但 Remote Control 的后台连接没有自动正确继承代理。通过 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 显式启动 Codex 后，连接便建立成功。

补充一点：上面的 export 设置只对这次从终端启动的 Codex 有效。退出应用或重启 Mac 后，通常需要再次设置；如果要长期生效，应根据自己的代理软件和 macOS 启动方式，采用可控、可恢复的持久化方案。

进阶：做一个专用的“Codex 代理启动器”，重启后也自动生效

手动 export 每次都要打开终端，太麻烦。我更推荐把它做成一个专用的启动器——只给 Codex 注入代理，不影响其他任何软件，而且重启 Mac 后也能自动启动。

思路是：用 macOS 自带的 osacompile 编译一个很小的 AppleScript 应用。这个应用启动后，会先等待 8 秒，让代理软件完成启动，再带着代理环境变量打开 Codex。

先完全退出 Codex，然后在终端一次性执行下面这段命令：

生成 Codex-Proxy-Launcher.appmkdir -p “$HOME/Applications” osacompile \ -o “$HOME/Applications/Codex-Proxy-Launcher.app” \ -e ‘delay 8’ \ -e ‘do shell script “export HTTP_PROXY=http://127.0.0.1:33210; export HTTPS_PROXY=http://127.0.0.1:33210; export ALL_PROXY=socks://127.0.0.1:33211; /usr/bin/open -a Codex”‘

执行后会生成：个人目录 → Applications → Codex-Proxy-Launcher.app。

然后完成两项设置：

1）加入开机登录项

打开「系统设置 → 通用 → 登录项」，添加 Codex-Proxy-Launcher.app

2）拖到程序坞备用

以后需要重新启动 Codex，就先完全退出 Codex，再点击这个启动器

启动器会先等待 8 秒，让代理软件完成启动，再带着代理环境变量打开 Codex。

有几个小提醒：

• 登录项里如果已有原版 Codex/ChatGPT 自动启动，请将原版关闭，只保留代理启动器。
• 代理软件本身也要设置为开机启动，这样 8 秒后才等得到它就绪。
• 如果代理端口以后改变，需要重新生成启动器（把命令里的端口改成新端口再跑一遍）。

这个方案是干净、可逆的。要取消时，删掉登录项，再把 Codex-Proxy-Launcher.app 移到废纸篓即可——它不会修改任何系统网络配置，也不会影响其他软件。

如果你也遇到同样的问题，可以这样判断

如果你的情况同时符合以下特征：

• ChatGPT/Codex 桌面版可以正常使用
• 主功能没坏，网络看似没问题
• 手机端已有 Remote Control 入口
• 且手机和 Mac 登录同一账号、Workspace 一致
• Mac 点击「允许」时始终提示无法启用
• 反复点、重启、重配对都无效
• 你的网络环境需要代理才能访问 ChatGPT

那就很值得检查 Remote Control 是否真正走了代理

先查看当前 macOS 代理：

查看系统代理scutil –proxy

再分别测试直连和显式代理。如果出现“直连超时、指定代理立即建立连接”，就和我这次的问题非常接近。

为什么这次真的解决了？

回头看，这次能把问题彻底解决，我觉得有两个很明显的原因。

第一个，是 ChatGPT 这次明显更有耐心。

它没有在给出两三个常规建议以后就停下来，而是持续跟着现场往下走：我发截图，它判断下一步；我执行命令，它读取结果；发现判断不对，就继续排除；怀疑版本，就升级验证；版本排除后，再去查日志、查代理；最后用两个 curl 对照实验，把问题锁定到代理继承。

整个过程走了不少弯路，但真正重要的是：AI 没有因为前面的判断失败，就停在一个似是而非的答案上。它持续利用新的现场信息修正判断。

第二个原因也许更有意思：ChatGPT 似乎更容易排查自己生态里的问题。

这不是说它一定比其他模型更聪明。我此前也查过资料，也问过豆包，但始终没有真正解决。区别在于，这一次它面对的是一整套自己的产品体系：手机 ChatGPT、ChatGPT/Codex 桌面端、Codex Remote Control、官方帮助文档和 Codex 日志。

它更容易把这些信息串成一条连续的排查链路：知道该区分账号、Workspace 与项目；知道升级可以验证版本假设；知道在日志里重点追踪 remoteControl、enable、ConnectionCount 和 errorCode；再把日志现象与代理测试结合起来，逐步逼近根因。

所以，这次经历也让我产生了一个新习惯：以后某个 AI 工具自己出了问题，可以先让它自己查自己。

AI 不只是告诉你”怎么使用一个工具”。当它越来越深入操作系统、开发环境和产品生态，它也开始具备一种很有意思的能力：诊断自己的工具链。

当然，它依旧会判断错。这次中间也有一些方向并不准确。但只要人持续提供真实的现场反馈，AI 就可以不断修正。

比“连上了”更重要的，是这次协作方式

这次排障给我最大的启发，并不是手机终于能够接管 Codex。

而是我更清楚地看到了一种正在变得现实的协作方式：

1）人提供现场，执行实验

点按钮、截图、跑命令，把真实结果反馈回去

2）AI 分析现象，提出假设

查文档、读日志、给排查命令

3）人把新的结果反馈回来

执行结果变成下一个判断依据

4）AI 根据证据修正判断，继续逼近根因

判断错了就推翻，用新证据重新定位

它不是”把错误信息扔给 AI，等待一个标准答案”。它更像是一个持续的调试伙伴：人拥有现场和行动能力，AI 拥有整理线索、调用知识、持续推理的能力。

这次问题最后只用了几条命令解决，但真正有价值的不是那几条命令，而是它们之前那条不断缩小范围的证据链。

不是 AI 一次回答对了，而是人和 AI 一起把问题逼到了根因。

人不需要一直坐在电脑前，但 AI 可以继续工作

现在，我又多了一种工作方式：Mac 放在那里让 Codex 干活，我拿着手机出去，也能随时查看进度、继续推进任务。

也许这才越来越接近我理解中的 AI Coding：人不需要一直坐在电脑前，但 AI 可以继续工作。

而这一切，靠的不是更贵的设备，也不是更专业的运维团队，而是——一个人，知道怎么把问题描述清楚、怎么把现场反馈回去、怎么和 AI 一起把问题一步步逼到根因。

这就是我一直说的AI 超级个体（OPC，One Person Company）的样子：一个人，不用招人、不用养团队，只要懂得如何定义问题、如何调度 AI、如何对结果负责，就能撬动一支过去根本无法企及的”虚拟军团”。

一个远程控制的小问题，也是一个小小的缩影：没有现场操作手册，没有资深运维在场，我一个人，加上 ChatGPT，把它彻底解决了。