手机 ChatGPT 连接电脑 Codex 一直离线？Mac 上 remote-control daemon 的排查与修复

问题现象：手机能看到电脑设备，但 Codex 一直显示离线

这个问题的典型表现是：手机端 ChatGPT App 的 Codex 连接页面里，已经能看到电脑设备名称、系统架构，甚至还能显示应用服务端信息，但设备状态始终是“离线”，点击重新连接也没有效果。

这种现象很容易让人误判。因为设备既然能显示出来，说明它并不是完全未被识别；但“能看到设备”不等于“电脑端已经具备可远程控制的在线状态”。实际排查中，真正卡住的往往不是手机网络，也不是桌面 App 是否打开，而是 Mac 端负责远程控制的后台 daemon 没有准备好，或者它虽然启动了，却无法正常连到服务端。

一个很关键的判断：桌面 App 正在运行，不代表 remote-control daemon 一定正常；CLI 能执行，也不代表 standalone managed install 已经就绪。

适用场景

下面这套排查思路，适合以下情况：

• 手机 ChatGPT 能看到电脑上的 Codex 设备，但状态一直离线；
• Mac 上 Codex App 已经打开，看起来也有相关进程；
• 你怀疑是局域网、防火墙、代理、CLI 安装或后台服务问题，但暂时无法定位；
• 当前网络环境访问 ChatGPT / OpenAI 需要代理，或者安装脚本偶尔返回 403、限流等错误。

如果你的环境与这里不同，例如系统平台不是 macOS，或产品行为已更新，请以官方最新文档和当前客户端提示为准。

这次排查里最容易误判的几个方向

一开始，最容易怀疑的是这些常见原因：

• 手机和电脑不在同一个局域网；
• 手机没有使用和电脑一致的代理；
• macOS 防火墙拦截了连接；
• Codex App 没打开；
• Codex CLI 太旧。

这些方向并不是完全不用查，但如果手机端已经能看到设备信息，重点通常不在“手机能否直接访问电脑某个端口”，而在“Mac 端是否已经把自己注册成一个可远程控制的在线设备”。这背后依赖的往往是 app-server daemon、控制 socket、standalone Codex 安装，以及 daemon 自身的网络连通性。

常见原因：为什么会出现‘能看到设备但一直离线’

1. Codex App 在运行，但 remote-control daemon 没有正常启动

先看进程，可能会发现桌面应用和 app-server 都在：

ps aux | rg -i 'codex|chatgpt'

如果能看到类似桌面应用主进程和 codex app-server 相关进程，只能说明应用层面在运行，不能直接证明远程控制通道已经可用。

进一步检查 daemon 状态时，如果出现类似下面的报错，就说明控制通道本身没有起来：

/Applications/Codex.app/Contents/Resources/codex app-server daemon version

Error: failed to connect to ~/.codex/app-server-control/app-server-control.sock

这类错误的核心含义是：控制 socket 不存在，daemon 没有正常准备好。

2. 缺少 remote-control 依赖的 standalone Codex 安装

这是这次排查中的第一个真正根因。即使 /Applications/Codex.app 已经存在，也不代表后台 daemon 依赖的 standalone Codex 已经安装到用户目录。

优先检查这个路径是否可执行：

~/.codex/packages/standalone/current/codex --version

如果路径不存在、软链接失效，或者命令无法执行，那么 remote-control daemon 很可能无法正常 bootstrap。

这也是很多人会踩的坑：桌面 App 安装成功，不等于 managed standalone install 已经就绪。

3. 安装脚本入口可访问性异常，或被限流卡住

如果你按客户端提示执行安装脚本，却遇到 403，不一定代表安装包本身不可用，也不一定说明产品已经不可安装。实际情况可能是：

• 入口域名在当前网络环境下被访问策略拦截；
• 安装脚本内部还会访问 GitHub API 等接口；
• 匿名 API 请求额度耗尽后，脚本会在“获取最新版本信息”这一步失败。

这类问题的特点是：脚本失败，但手动下载 release 包未必失败。也就是说，失败点可能在“安装流程的元数据获取”，而不是“二进制包本身无法下载”。

4. daemon 启动了，但没有继承代理环境

这是第二个高频根因，尤其是在必须通过代理访问 ChatGPT / OpenAI 的网络环境下。

很多人会在 shell 里配置好 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，然后默认认为后台 daemon 也会自动继承。但实际并不一定如此。daemon 如果是由其他方式拉起，或者首次 bootstrap 时没有带上代理环境，它可能会直接尝试外连，最终导致手机端仍然显示离线。

所以“daemon version 返回 running”并不等于“它已经真正在线”。还要继续验证它是否拿到了代理环境，以及网络连接是否走了本机代理。

分步解决方案：按这个顺序查，效率最高

第一步：确认 standalone Codex 是否存在

先执行：

~/.codex/packages/standalone/current/codex --version

判断标准：

• 如果命令能正常返回版本信息，说明 standalone Codex 基本存在；
• 如果提示文件不存在、权限错误或路径无效，先不要反复重装 App，优先补齐 standalone install。

如果官方当前推荐的安装方式可用，优先使用官方方式。如果官方入口在你的网络环境下返回 403，或者安装脚本被 API 限流卡住，可以考虑改用官方 release 页面中当前可用的安装包来源，手动下载对应架构的包并校验后放到 Codex 期望的目录结构中。

这里不要写死某个版本号或包名。不同时间、不同芯片架构、不同发布方式下，文件名可能变化，实际以官方当前发布页为准。

第二步：检查 daemon 控制 socket 是否存在

执行：

ls -la ~/.codex/app-server-control

重点看是否存在类似下面的控制 socket：

app-server-control.sock

如果目录存在但没有 socket，或者目录本身都不存在，通常说明 daemon 没有成功启动。

这一步非常关键，因为手机端“离线”的本质，往往就是电脑端没有可用的 remote-control 控制通道。

第三步：尝试启动或重建 remote-control daemon

在 standalone Codex 已经存在的前提下，可以尝试执行：

~/.codex/packages/standalone/current/codex app-server daemon bootstrap --remote-control

如果成功，通常会返回一段状态信息，里面会包含 daemon 是否已 bootstrapped、remote control 是否启用、socket 路径、当前 managed Codex 路径等内容。

随后再检查：

~/.codex/packages/standalone/current/codex app-server daemon version

如果返回 running，且 socket 文件已经出现，说明 daemon 至少已经在本机层面启动成功。

第四步：确认 daemon 是否真的继承了代理环境

如果你的网络环境访问相关服务必须走代理，这一步不能省。

可以先重启 daemon，并显式带上代理环境变量：

HTTP_PROXY=http://127.0.0.1:7890 
HTTPS_PROXY=http://127.0.0.1:7890 
ALL_PROXY=socks5://127.0.0.1:7890 
NO_PROXY='localhost,127.0.0.1,::1' 
~/.codex/packages/standalone/current/codex app-server daemon restart

然后检查 daemon 进程环境中是否真的带上了这些变量。思路可以是先找到 daemon 的进程号，再查看环境变量：

ps aux | rg 'codex app-server'
ps eww -p <PID> | tr ' ' 'n' | rg -i 'proxy|http|https'

判断标准：

• 如果能看到 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY，说明环境变量已传入；
• 如果完全看不到这些变量，说明 daemon 很可能仍在直连外网。

注意：这里的 127.0.0.1:7890 指的是 Mac 本机代理端口，不是手机要访问的地址。手机上的 127.0.0.1 只代表手机自己，不代表电脑。

第五步：检查网络连接是否走了本机代理

仅看环境变量还不够，最好再看实际连接。可以继续用进程号检查网络连接：

lsof -nP -p <PID> -a -i

判断思路：

• 如果看到 daemon 直接连向外部公网 IP 的 443，且状态长期异常，说明它可能在直连；
• 如果看到它先连向本机代理端口，例如 127.0.0.1:7890，通常说明代理链路已经生效。

这一步能帮助你区分“daemon 已启动但无法联网”和“daemon 已启动且网络路径正确”这两种完全不同的状态。

如何验证是否修复成功

建议按下面的顺序验证，而不是只看手机页面是否偶尔刷新：

1. standalone 可执行文件存在且能运行

   ~/.codex/packages/standalone/current/codex --version

2. daemon 状态正常

   ~/.codex/packages/standalone/current/codex app-server daemon version

   预期是返回 running 或等价的正常状态。

3. 控制 socket 已创建

   ls -la ~/.codex/app-server-control

   预期能看到 app-server-control.sock。

4. daemon 进程已继承代理环境

   ps eww -p <PID> | tr ' ' 'n' | rg -i 'proxy|http|https'

5. 网络连接路径正确

   lsof -nP -p <PID> -a -i

   预期是通过本机代理访问外网，而不是盲目直连。

6. 手机端状态从离线变为可连接

   当前面几项都正常后，再回到手机 ChatGPT App 的 Codex 页面刷新状态。此时如果设备从离线变为可连接，基本可以确认问题已经落在 daemon 与网络层，而不是手机端本身。

几个非常容易踩的坑

误区一：以为手机必须和电脑在同一局域网

如果设备信息已经能显示出来，问题重点通常不是手机能否直接访问电脑上的某个局域网端口。很多情况下，这类连接更像是通过服务端同步设备在线状态，而不是手机直接扫到电脑本地服务。

误区二：以为 Codex App 打开就代表远程控制可用

这是最常见误判。应用主进程存在，只能说明 App 打开了；真正决定手机端是否能连上的，是 remote-control daemon、控制 socket、standalone install 和网络连通性。

误区三：以为防火墙一定是根因

防火墙值得检查，但如果系统防火墙本身已关闭，或者没有启用阻断全部连接，就不要一直停留在这个方向。继续查 daemon 和代理，通常更有效。

误区四：以为安装脚本失败就等于无法安装

脚本失败可能只是入口 403、下载链路受限，或者安装脚本内部访问 API 时被限流。此时要区分“脚本流程失败”和“安装包本身不可获取”这两件事，不要混为一谈。

误区五：daemon 返回 running 就以为问题已经解决

running 只说明进程活着，不说明它已经成功连到服务端。尤其在需要代理的环境下，必须继续确认代理环境和实际网络连接。

解决不了时的补充建议

如果按上面的顺序排查后仍然无法恢复，可以继续从以下几个方向补充信息：

• 重新收集 daemon 启动输出：保留 bootstrap 或 restart 的完整终端输出，重点看是否有路径缺失、权限错误、网络错误。
• 检查用户目录权限：确认 ~/.codex 目录及其子目录可读可写，避免因权限异常导致 socket 或软链接无法创建。
• 核对当前登录账号：如果桌面 App、CLI、daemon 分别在不同用户上下文中运行，路径和环境变量可能不一致。
• 确认代理工具本身可用：本机代理端口必须真实监听，且能正常转发目标流量。否则即使 daemon 带上了代理变量，也仍然无法在线。
• 避免混用多个代理变量：如果同时设置了系统代理、shell 代理、代理 App 规则和不同类型的环境变量，可能出现某些请求走代理、某些请求直连的混乱情况。
• 对照官方最新说明：如果近期产品有更新，命令路径、daemon 行为、安装方式都可能变化，建议以官方当前文档和客户端提示为准。

一套更稳妥的排查顺序

如果以后再次遇到“手机端能看到设备但一直离线”，建议直接按下面顺序走：

1. 检查 standalone 是否存在：~/.codex/packages/standalone/current/codex --version
2. 检查 daemon 是否 running：~/.codex/packages/standalone/current/codex app-server daemon version
3. 检查 socket 是否存在：ls -la ~/.codex/app-server-control
4. 检查相关进程：ps aux | rg 'codex app-server'
5. 检查 daemon 是否继承代理：ps eww -p <PID> | tr ' ' 'n' | rg -i 'proxy|http|https'
6. 检查实际网络连接：lsof -nP -p <PID> -a -i
7. 必要时显式带代理重启 daemon，再回手机端刷新状态。

这个顺序通常比反复重装 App、切换手机网络、反复点击重新连接更有效，因为它直接针对真正决定在线状态的几个关键点：standalone、daemon、socket、代理继承和网络路径。

结论

手机 ChatGPT 能看到电脑上的 Codex 设备，却一直显示离线，很多时候并不是局域网问题，也不一定是 macOS 防火墙导致。更常见的根因是：

• Mac 端缺少 remote-control daemon 依赖的 standalone Codex；
• daemon 没有正常启动，导致控制 socket 不存在；
• daemon 虽然启动了，但没有继承代理环境，最终无法真正在线。

真正有效的修复路径通常是：先补齐 standalone Codex，再启动或重建 remote-control daemon，确认 app-server-control.sock 已出现，然后在需要代理的环境下显式带代理重启 daemon，并验证它的实际网络连接是否走了本机代理。

遇到这类问题时，不要只看“App 是否打开”，而要重点检查后台 daemon、socket 文件、standalone 安装和代理继承情况。只要这几个点理顺，手机端“能看到设备但一直离线”的问题通常就能定位清楚。

转载请注明：AI工具问题解答站 » 手机 ChatGPT 连接电脑 Codex 一直离线？Mac 上 remote-control daemon 的排查与修复