手机直连 Codex：用飞书或微信，把电脑上的同一件事继续做下去

一句话结论：能用 OpenAI 官方 Remote，就先用官方；如果你在中国大陆，官方移动端受网络条件影响，或者你本来就长期待在微信、飞书里，再做本地桥接。但真正的“打通”不是手机能收到一句回复，而是手机和电脑始终续接同一条 Codex 任务，失败不撒谎，息屏、重启以后还能回来。

我为什么非要在手机上控制 Codex

我不是为了炫技，也不是嫌电脑不好用。

我经常离开电脑：走在路上、躺下休息、在公司处理别的事，脑子里突然冒出一句补充。如果一定要等回到 Mac 前再说，这个念头可能已经变味了；如果手机上重新开一个 AI，又会丢掉电脑里刚才的代码、文件、规则和上下文。

OpenAI 已经提供官方 Remote：在电脑端开启远程连接，用手机扫描二维码，之后可以从移动端访问这台主机。它是最短、维护成本最低的路线，也应该是普通人的第一选择。

但我人在中国大陆。官方移动端往往还受网络工具、线路延迟和登录环境影响：能用，不一定随时顺手；临时补一句话，却要先处理网络，本末倒置。微信和飞书恰好是我每天都开着的入口，消息到达快，语音转文字也自然。所以我想要的是：直接在微信或飞书里喊一声“豆豆”，家里电脑上的 Codex 就接着刚才那件事干。

这条路线更顺手，也更难。因为微信、飞书只是消息入口，不是 Codex 官方 Remote。你必须自己承担会话绑定、权限、进程、消息可靠性和安全边界。

先看懂：不是把 Codex 搬进微信

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

真正稳定的结构只有一句话：两个入口，一道网关，一条固定任务，一个写手。

微信和飞书负责收消息、回消息。
本地网关负责保存、排队、去重、路由和送达。
稳定的任务编号负责认出“还是电脑上这件事”，不能只靠标题。
Codex 继续在电脑上读原项目、原文件和原规则。
同一条任务同一时刻只能有一个执行者，避免桌面和后台同时写。

如果微信和飞书各自启动一套 Codex，它们都会说“收到”，却是在两张桌子上干活。手机里看似成功，回到电脑后没有记录；或者两个执行者同时改同一件事，结果互相覆盖。这是第一大坑。

两条路线怎么选

你的情况	建议	代价与边界
能稳定使用 ChatGPT 移动端，只想远程看进度、补要求、处理确认	先用 OpenAI 官方 Remote	配置最少，官方维护；仍要保证电脑在线、账号与权限正常
长期使用微信或飞书，大陆网络下希望入口更丝滑	做本地桥接	入口顺手，但网关、会话绑定、日志、安全和恢复都由自己负责
只想偶尔从手机触发一个固定脚本	不必续接完整任务，可做窄命令入口	权限更小，但拿不到完整对话上下文
涉及付款、发布、删库、验证码或隐私数据	手机只发起请求，关键闸门仍由本人确认	不能因为入口方便就扩大自动权限

别一开始就自建。先试官方 Remote；只有它在你的真实网络和工作习惯里确实不顺，微信或飞书又是高频刚需，才值得承担本地桥接的维护成本。

我以为是一个问题，后来发现是六个

我前后折腾了十天。手机端反复出现同一句“这条消息没处理完”，看起来像一个故障，实际上每次根因都不一样。

1. 能回复，但回错了对话

第一版飞书能收能回，微信也能收能回。回到电脑一看，原任务没有任何变化。后台悄悄另开了一条会话，手机和电脑并不是同一个现场。

修复不是“把标题改成一样”，而是让两个入口都绑定同一个稳定任务编号。标题给人看，编号才是机器身份。

2. 同一条记录，却有两个写手

消息写进同一个任务，也不代表安全。桌面 Codex 和后台 app-server 可能同时认领它。于是出现重复执行、状态覆盖、回复错位。

必须先判断桌面是否已经拥有这条任务；只有明确没有别的写手时，后台才能续接。对同一个会话还要串行执行，不能一条消息没结束，第二条又抢进去。

3. 把息屏当成根因，补丁越打越多

电脑息屏后消息失败，我们最初以为是“看不见屏幕”。后来发现，息屏只是表象：桥接程序依赖桌面 UI 找任务；负责读取界面的守护进程曾被 macOS 因内存压力结束，也曾被别的软件卸载误伤。进程还在时一切正常，电脑一重启，断链才暴露。

正确做法不是让程序更努力地点界面，而是把 UI 从关键路径拿掉：已知稳定任务编号、并确认没有桌面写手时，直接通过 Codex app-server 续接同一条任务。UI 自动化只能做降级辅助，不能做唯一生命线。

4. 固定任务被归档，普通续接必然失败

为了清理侧栏，那条长期手机入口曾被当成普通任务归档。飞书消息其实已经收到，本地服务也在线，但 Codex 拒绝继续一个已归档任务。

不要新建一条同名任务糊弄过去。OpenAI app-server 对归档和恢复有明确能力：先 thread/unarchive，校验恢复的仍是原任务，再 thread/resume。长期基础设施入口还应置顶，并排除自动改名、归档和批量清理。

5. 旧微信服务“死而复生”

旧版微信桥接曾经停用，但只停止了当时的进程，没有永久禁用系统启动项。电脑重启后，它又自动复活，和新网关争抢同一批微信消息，还各自启动执行服务。

所以“我已经停掉它了”不是证据。必须同时确认启动项已禁用、进程树里只剩一个网关、端口只有一个监听者，并在重启后再查一次。

6. 最危险的不是失败，而是假完成

有一次机器人对我说：“这条消息没处理完，你继续发，我这边会接着处理。”听起来很体贴，后台却已经把失败记录成 done。它不会继续，也没有进入重试队列。

从那以后，我不再接受模糊的“已处理”。一条消息至少要分成这些状态：

received → persisted → claimed → running
                         ↓
             retry_scheduled / failed
                         ↓
completed → reply_pending → delivered

“收到”不等于“保存”，“开始”不等于“完成”，“完成”也不等于“手机已经收到”。说会重试，后台就必须存在真实重试记录；做不到就坦白说失败，让人重新发送。

真要搭，按这个顺序做

第一步：先固定唯一身份

在电脑上选一条专门承接手机消息的 Codex 任务，保存它的稳定编号。微信私聊、飞书私聊和需要开放的群聊，都只映射到这个编号。标题可以变，编号不能漂；不要按“搜索到第一个同名标题”来绑定。

第二步：让消息先落盘，再执行

网关收到消息后，先写入可靠存储，再回复“收到”。为每条平台消息保存唯一 messageId、来源、会话、附件、状态、尝试次数和最后错误。先保存，才能在进程崩溃后知道哪些没做完。

图片、文件或视频不能只保存成 (image)、(file) 这样的占位文字。二进制文件或可再次下载的媒体标识必须在入队前保留下来；历史记录如果只有占位符，事后通常无法恢复，只能请用户重发。

第三步：锁住单一写手

同一个 Codex 任务必须串行。桌面正在执行时，后台不要抢；后台接手时，要有租约、心跳和超时释放。跨任务可以并行，同一任务不要并行写。

第四步：只在精确条件下自愈

自动恢复必须窄：只有“这是登记过的固定手机任务”“错误明确表示它已归档”“恢复结果仍是同一个编号”三项同时满足，才允许自动取消归档并重试一次。认证失败、网络失败、其他任务归档一律保持失败，不要扩大权限。

第五步：把旧系统真正关死

升级到统一网关以后，检查旧微信服务、旧飞书服务、旧 app-server、启动项、守护进程和监听端口。停止当前进程只是第一步；还要禁用自动启动，并做一次重启后的进程树复核。

第六步：最后才谈体验

链路可靠以后，再加语音转文字、图片附件、任务分类、长任务转交、日记或提醒。不要在消息还会丢、会双写时，先堆一层漂亮功能。

怎样才算真的打通

我最后不用“服务在线”作为完成标准，而是做一组真人验收：

从微信发一条自然消息，不用专门测试口令。
确认它进入电脑侧同一条固定任务，没有另开影子任务。
确认 Codex 真正开始执行，并把结果原路送回微信。
再从飞书发一条，重复同样检查。
电脑只息屏、不睡眠时再测一次。
重启电脑后，确认只有一个网关和一个执行服务，再测一次。
人工归档固定任务，验证系统只恢复这一个精确入口；普通任务不会被擅自恢复。
人为制造一次失败，确认状态是 failed 或真实 retry_scheduled，绝不能显示 done。
发送一张图片或文件，确认 Codex 收到的是真实附件，不是一个占位词。

只有“手机收到回复、电脑同一任务可见、后台状态一致”三者同时成立，才叫远程可用。单元测试通过、健康接口返回 200、机器人回了一句话，都只能算其中一层。

安全边界别因为方便而消失

手机入口默认只开放给本人或明确白名单，不接受任意陌生人触发本机 Codex。
平台凭据、Token 和本机路径不写进聊天回复；日志要脱敏并限制权限。
发布、付款、删除、验证码、实名和高风险系统修改仍需本人确认。
网关只得到完成当前工作的最小权限；不要为了省一次确认，把整台电脑永久暴露出去。
官方 Remote 和自建桥接都依赖电脑在线。需要真正离线运行时，应另选 Codex Cloud 等云端路线，不能假装本机已经在工作。

给下一位 AI 的提示词

请把“手机直连 Codex”当成可靠消息系统，而不是聊天机器人接线。

先核对 OpenAI 当前 Remote 与 app-server 官方能力，再审计现有微信/飞书网关：
1. 两个渠道是否绑定同一稳定 threadId，而不是按标题找任务；
2. 桌面与后台是否保持单一写手，同一会话是否串行；
3. 消息是否先持久化，并区分 received、persisted、running、completed、delivered、failed；
4. 附件是否保存真实二进制或可回取 mediaId，而不是只有占位文字；
5. 固定任务被归档时，是否只对精确 threadId 执行 unarchive → same-id 校验 → resume；
6. 旧 LaunchAgent、旧网关和第二 app-server 是否已禁用并经重启复核；
7. 是否存在把 engine error 改写成友好话术、随后标成 done 的假完成。

不要先改代码。先用日志和状态库还原一条失败消息从收到到送达的全链路，再做最小修复。
最后分别用真实微信、真实飞书、息屏和重启场景验收；机器测试、服务在线和 HTTP 200 不得冒充用户侧通过。

来源与修订

OpenAI 官方 Remote 的入口与配对方式以官方 Remote connections 文档为准；Codex app-server 的任务续接、归档与恢复以官方 app-server 文档为准。微信、飞书桥接是小龙哥基于真实使用环境搭建的本地方案，不是 OpenAI、微信或飞书提供的原生 Codex 功能。

本文保留固定地址 /exp/mobile-codex/，旧 /kits/001/ 继续兼容。以后入口参数小改继续修订本文；只有官方能力或整体路线发生实质变化，才另开新篇。