手机直连 Codex：我修了十天，才明白“能回消息”根本不算打通

一句话结论：先用 OpenAI 官方 Remote。确实需要微信或飞书时，再用成熟开源网关接渠道。自己只补官网和通用工具不知道的那一小段：哪条任务是唯一入口、消息有没有真的落盘、归档后能不能精确恢复、失败有没有说真话。

我想要的，其实只是出门后还能补一句话

这件事一开始听起来很简单。

我在 Mac 上让 Codex 做事，走开以后突然想到一句补充，就在微信或飞书里发给“豆豆”。家里的电脑继续原来那件事，做完再把结果发回来。

不是在手机上再开一个 AI，也不是远程看电脑屏幕。我只想回到同一张工作台：原来的项目、文件、规则和对话都在，手机只是多了一个入口。

OpenAI 已经有 Remote。官方文档写得很清楚：手机可以继续电脑上的现有对话、补充要求、处理确认、看输出。主机睡眠、断网或退出应用后，远程访问会停止。只要你的网络和账号环境合适，这就是第一选择，配置少，也不用自己维护消息通道。

我在中国大陆长期使用微信和飞书。它们打开更快，语音、图片和日常聊天也顺手，所以才做了本地桥接。这里要先把话说透：本地桥接不是比官方高级，只是更贴合我的日常入口，代价是可靠性和安全都要自己负责。

先别写代码，看看官网已经做了什么

这次最值钱的教训，不是某一段修复代码，而是先停下来查官网。

OpenAI app-server 已经提供 thread/resume、thread/archive 和 thread/unarchive。任务被归档后，继续请求会被拒绝；正确动作是恢复原任务，再续接。服务器拒绝一个已归档任务，不是它坏了，反而是在守边界。

GolemBot 已经负责飞书长连接、断线重连、图片和文件转发，也有官方续跑能力。我们一度自己写过相似的 watchdog 和续跑逻辑，后来对照新版才发现，官网已经修了。那部分本地代码应该删，不该继续背着两套实现。

截至 2026 年 8 月 9 日，GolemBot 的 GitHub 与 npm 最新稳定版是 0.48.4。这个版本只更新了模型供应商预设，没有增加“固定 Codex 任务被归档后自动恢复”。这也说明了边界：通用工具知道怎样接飞书、微信和 Codex，却不知道你家里哪一条任务是不能归档的基础设施。只有这部分，才值得做最小的本地补充。

以后碰到类似问题，我会先问三句：

官网现在有没有现成能力？
当前安装的是不是已经包含修复的版本？
我准备写的代码，是通用能力，还是只有我的业务才知道的规则？

前两项能解决，就升级和配置。只有第三项才自己写。

接消息和操作飞书，不是同一层

这里很容易再绕一次弯路。

飞书长连接或 GolemBot 负责把小龙哥的一句话送到豆豆；豆豆真的去查联系人、发消息、改任务、读文档、操作知识库时，应该使用国内版飞书的官方 lark-cli 或 OpenAPI。前一层是消息入口，后一层是业务控制面。

控制面不依赖飞书桌面窗口，也不靠坐标点击。每次操作都显式写清 user 还是 bot，先解析精确对象，写入支持时先 dry-run，创建或发送带幂等键，成功后按返回 ID 回读。CLI 报错、OAuth 过期或权限不足时，就修 CLI 和权限；不能悄悄换机器人身份，也不能退回界面“点一下试试”。完整开箱方法见把飞书交给豆豆：国内版、CLI、本人身份一次打通。

正确关系：手机只是门，不是第二间办公室

手机直连 Codex 的正确关系：微信和飞书只是入口，统一网关把消息送进电脑上的同一条 Codex 任务两个入口只负责送消息，统一网关把它们收回同一条 Codex 任务。

稳定结构可以用一句话说完：两个入口，一道网关，一条固定任务，一个写手。

微信和飞书收消息、回消息。
GolemBot 处理渠道连接和通用消息格式。
本地可靠层先保存，再排队、去重和记录状态。
稳定的 threadId 把消息送回电脑上的同一条 Codex 任务。
Codex 继续读原项目和原文件，同一任务同一时刻只允许一个写手。

标题不是身份。标题可以改名，也可能重名；threadId 才是那条任务的身份证。

如果微信和飞书各开一条新任务，手机上照样会收到漂亮回复，但电脑里原来的工作没有继续。更糟的是，两边同时改一个文件，最后谁覆盖谁都说不清。那不叫远程协作，只是两个人拿着同一份稿子各改各的。

我们为什么修了十天

手机反复出现“这条消息没处理完”，看起来每次都一样。真实情况是，同一句话背后换了好几个根因。

发生了什么	当时以为	后来查到
手机能回，电脑原任务没变化	已经接通	后台另开了影子任务
息屏后失败	屏幕黑了，程序看不见	桥接把桌面界面当成唯一入口
屏幕亮着也失败	还是息屏补丁不完整	固定任务没渲染在侧栏，UI 查找失效
隔一阵又失败	网关不稳定	桌面驱动被内存压力终止，缓存也丢了
修好后隔天再失败	修复没生效	固定手机任务被当成普通任务归档
微信重启后又抢消息	新网关有问题	旧启动项只是停过，重启后又复活

这张表有个共同点：表面都像“息屏坏了”，实际故障分别发生在身份、桌面界面、任务生命周期和系统启动项。

最容易犯的错，是看到一个现象就给它起名字，然后所有补丁都围着这个名字写。真正的排查要沿着消息走：平台有没有收到，是否保存，送进了哪条任务，谁在执行，结果有没有送回来。走到哪一步停了，根因才在哪一层。

最后一轮到底修了什么

最终复发时，主机在线，飞书消息也已经收到。可靠 Inbox 里有原消息，网关进入了无界面续接，随后 OpenAI app-server 明确返回：目标任务已经归档，不能继续。

这不是息屏，也不是服务宕机。那条长期手机入口在几天前清理侧栏时被归档了。

我们没有新建一条同名任务糊弄过去，而是使用 OpenAI 官方能力恢复原 threadId，再校验返回的仍是同一个编号，然后 resume。这条任务同时被置顶，并写进侧栏整理规则：普通任务可以归档，固定手机入口不能被批量清理、改名或迁移。

同一轮又查到，两个旧微信 LaunchAgent 以前只做过 bootout。这只能让它们当下停止，并没有持久禁用。电脑重启后，旧微信服务和旧 app-server 一起复活，重新和统一网关抢消息。最终处理是保留可回退配置，但对旧启动项执行持久禁用，再重启复核进程和端口，确认只剩一个网关、一个执行入口。

最后的自愈很窄：只有登记过的固定手机 threadId 遇到官方“已归档”错误，才允许 unarchive → 同 ID 校验 → resume。认证失败、网络失败、普通任务归档都保持失败。自动化不是权力越大越聪明，条件越精确才越安全。

修复后，定向测试、完整回归、真实绑定任务的本机回归都通过了。但当时我们仍没有说“彻底好了”。因为这些只能证明候选没有明显坏，不能代替小龙哥从真实手机使用。

隔天再次在真实入口使用，链路仍然正常。小龙哥明确确认：“最后一次终于把它修好了。”到这一步，才从机器通过升级为用户验收通过。

普通人照着走的十分钟排查法

下次手机又不回，先别重装，也别立刻改代码。按顺序查。

1. 主机真的可用吗

确认电脑在线、没有睡眠、网络正常，ChatGPT 或 Codex 主程序仍在。息屏和睡眠不是一回事：屏幕黑着，主机可以继续工作；真正睡眠后，官方 Remote 和本地桥接都会停。

2. 渠道收到消息了吗

去渠道日志找这条消息的 messageId。飞书 WebSocket 或微信轮询都没收到，问题在渠道连接；不要去改 Codex 任务。

3. 消息保存了吗

看到消息不等于保存成功。可靠 Inbox 里应该有原文、来源、messageId、附件和当前状态。没有落盘就先修存储，否则进程一崩，连“丢了什么”都不知道。

4. 它进了哪条任务

用 threadId 查，不要靠标题猜。若生成了新任务，先修绑定；若原任务已归档，走官方 unarchive；若任务仍在运行，检查是不是另一个写手已经拥有它。

5. 结果停在哪个状态

一条消息至少要分清：收到、已保存、执行中、已完成、待回送、已送达、失败、已安排重试。

received → persisted → running → completed → delivered
                         ↘ failed / retry_scheduled

“机器人回了一句话”和“Codex 做完了”没有必然关系。系统若说稍后会继续，后台就必须有真实的重试记录；没有就老实报失败。

6. 重启后是不是又多出一套

查启动项、进程树和监听端口。停止一个旧进程不代表永久下线。真正完成要看重启以后旧服务没有复活，同一消息只有一个消费者。

这六步跑完，通常已经能确定故障在哪一层。还没找到，再写最小复现和最小补丁。

真正容易漏掉的四件事

附件必须先保存

图片和文件不能只留下 (image) 或 (file)。要保存真实文件，或者保存后续仍能下载的 mediaId。平台过期以后，只有占位符的旧消息通常救不回来。

同一任务只能有一个写手

微信和飞书可以同时进来，不代表同一条 Codex 任务可以并行写。跨任务能并行，同一 threadId 要排队，并用租约或锁防止桌面和后台双写。

失败要说人话，也要说真话

“刚才没处理完，你继续发，我会接着处理”听着很温柔。后台若已经记成 done，这句话就是假的。友好文案不能覆盖真实错误，更不能替代重试队列。

安全边界不能跟着手机入口一起放大

入口只开放给本人或白名单。付款、发布、删除、验证码、实名和不可逆操作仍要本人确认。方便发消息，不等于给任何聊天联系人一把整机钥匙。

怎样才算真的打通

我现在用下面这组标准验收，不再看一句“服务在线”就宣布完成。

微信发自然消息，进入指定的同一条 Codex 任务，结果原路返回。
飞书再发一条，仍是同一个 threadId，没有影子任务。
电脑息屏但不睡眠时再测，确认不依赖桌面 UI。
重启电脑后再测，进程树里只有一个网关和一个执行入口。
人工归档固定入口，确认只恢复这个精确 threadId；普通任务不会被擅自恢复。
人为制造失败，后台只能显示 failed 或真实 retry_scheduled，不能显示 done。
发送图片或文件，Codex 收到真实附件，不是占位词。
隔一天正常使用仍然通过，再由真实用户确认体验。

单元测试通过、健康接口返回 200、本机回归成功、正式服务已重启、真实手机可用、用户确认满意，是六层不同的证据。少一层，就按真实状态写，别把“候选”说成“彻底修好”。

可直接交给 AI 的提示词

请把“手机直连 Codex”当成可靠消息系统，不要只检查机器人能不能回话。

先查官网：
1. 核对 OpenAI 当前 Remote 与 app-server 的官方能力；
2. 核对所用网关的最新稳定版、更新记录和已实现的重连/续跑能力；
3. 官网已有的能力优先升级或配置，不重复实现。

再沿一条真实失败消息检查全链路：
1. 渠道是否收到真实 messageId；
2. 消息和附件是否先持久化；
3. 微信与飞书是否绑定同一稳定 threadId，而不是按标题找；
4. 桌面与后台是否保持单一写手，同一 threadId 是否串行；
5. 固定任务归档时，是否只对精确 threadId 执行 unarchive、同 ID 校验、resume；
6. 旧启动项、旧网关和第二 app-server 是否已持久禁用，并经重启复核；
7. received、persisted、running、completed、delivered、failed 和 retry_scheduled 是否分开记录；
8. 是否存在把引擎错误改写成友好话术后标成 done 的假完成。

先用日志和状态库还原故障停在哪一步，再做最小修复。
最后用真实微信、真实飞书、息屏、重启、归档和附件逐项验收。
机器测试、健康接口和本机回归不得冒充用户验收。

来源与修订

官方 Remote 的连接方式、主机在线要求和远程能力，以 OpenAI Remote connections 文档为准。任务续接、归档和恢复，以 OpenAI Codex app-server 文档为准。OpenAI Issue #26159 也记录了归档后继续 resume 被服务器正确拒绝的同类现象。

飞书长连接、pong watchdog、图片和文件转发，以 GolemBot 官方文档和 Releases 为准。飞书业务资源的查询和写入，以飞书官方 lark-cli 与 OpenAPI 为准。微信、飞书桥接中的固定任务、可靠 Inbox、单一写手和精确归档自愈，是小龙哥真实使用环境里的本地可靠性补充，不是 OpenAI、微信或飞书提供的原生能力。

本文保留固定地址 /exp/mobile-codex/，旧 /kits/001/ 继续兼容。以后官方版本和小参数变化继续修订本文；只有整条路线被新证据推翻，才另开新篇。