Codex 远程唤醒怎么做：Remote、Slack 和 App Server 该选谁

发表于
如果 Codex Agent 常驻 Mac mini，个人值守优先用 ChatGPT Remote；自建无人值守 Agent，才需要 App Server 加 Slack 或 Telegram 控制面。

假设一台 Mac mini 上有个 Codex Agent，能够自己接任务、改代码、跑测试，连续工作几个小时。

真正棘手的问题往往不是怎样让它开始，而是它做到一半发现需求不清楚、需要批准一条命令，或者准备汇报阶段结果时，怎样找到已经离开电脑的我。

很多人的第一反应是接 Telegram、Slack 或企业微信。我的判断是：如果这是我自己的 Mac mini，最合适的第一选择不是再造一个聊天机器人，而是使用 ChatGPT Remote；只有 Agent 是自建的常驻进程，或者需要进入团队协作频道时，才值得用 Codex App Server 接 Slack 或 Telegram。

因为所谓“远程唤醒”，其实混合了三件不同的事：

  1. 触发：人在外面时给 Agent 一个新任务；
  2. 通知：Agent 完成、失败或卡住时主动提醒人；
  3. 对话与控制：人回答问题、批准操作、改变方向，并继续同一个任务。

Webhook 能解决通知，聊天软件能提供界面，但只有把任务状态、权限和后续对话接回同一个 Agent 线程，才算真正的远程控制。

Mac mini 个人值守，ChatGPT Remote 已经覆盖了闭环

ChatGPT Remote 官方文档给出的使用方式非常接近这个场景：Codex 继续运行在已经连接的 Mac、Windows 或 SSH 主机上，手机则成为控制面。

在手机上可以开始或继续同一个聊天、发送后续要求、回答 Agent 的问题、批准操作、查看 diff、测试和终端输出。任务结束或需要注意时，Remote 还会发出通知。正在执行的任务既可以 Queue 一条消息，让它在下一轮处理，也可以 Steer，把新指示注入当前工作过程。

这比自建 Telegram Bot 少掉了最难维护的一层：会话映射。

Agent 在电脑上拥有什么仓库、Shell、MCP、Skill 和浏览器能力，仍然由这台电脑提供；手机只负责提示、审批和接管。权限沙箱也不会因为远程访问而消失。它不是把 Mac 的终端暴露到公网，而是通过安全中继连接已登录的设备。

它也有明确前提：

  • Mac mini 必须保持开机、联网，ChatGPT 桌面应用保持运行；
  • 手机和主机使用同一个账号及工作区，并完成配对；
  • 持续访问最好使用本来就长期在线的机器；笔记本睡眠、断网或退出应用都会中断连接；
  • Remote 提供的是“Agent 到关键节点提醒我，然后我进入同一对话处理”，不是让 Agent 任意给联系人发送私信。

对于一台常开的 Mac mini，这些限制反而很匹配。它天生适合承担执行端，手机承担随身控制端。

四种接入方式，解决的不是同一个问题

把常见方案放在一起，差别会更清楚：

方案 能主动提醒 能继续原任务 能审批与回答 更适合什么
ChatGPT Remote 可以 可以，直接回到同一聊天 可以 个人远程值守自己的电脑
Codex 原生 Slack 集成 可以在频道回帖 继续对应的云端任务 适合频道协作 团队从 Slack 派发 Codex Cloud 任务
App Server + Slack/Telegram 由自己实现 可以，需维护线程映射 可以，需实现按钮和回调 自建常驻 Agent、定制工作流
Hook/CLI 通知 + Webhook 可以 通常不行 不适合作为完整对话 完成、失败等单向告警

邮件也能发送通知，但不适合高频的人在回路（Human-in-the-loop）协作。邮件延迟高，审批体验差，也很难可靠地把一次回复关联到正确的 Agent、线程、轮次和待回答问题。它更适合日报和审计摘要，不适合中途接管。

所以，“接入什么聊天软件”不应该是第一个问题。第一个问题应该是：我要控制的是 ChatGPT 里正在运行的 Codex，Codex Cloud 任务，还是我自己实现的 Agent 进程？

原生 Slack 适合团队派单，但不是本地 Agent 的遥控器

Codex 的官方 Slack 集成允许团队在频道或帖子里 @Codex，由此创建 Codex Cloud 聊天，并把结果发回 Slack。

它很适合这样的场景：产品经理在问题讨论串里叫 Codex 调查一个 Bug，工程师都能看到任务和结果，代码仓库与云端环境也已经配置好。

但它不等于“连接我 Mac mini 上已经跑了三小时的那个 Agent”。原生集成创建的是云端任务；如果仓库和环境信息不够明确，还可能根据最近使用记录或默认设置选择目标。

因此我会这样区分：

  • 团队共享、云端执行、从频道发任务：用原生 Slack 集成；
  • 个人电脑、本地工具链、需要接回当前工作现场：用 ChatGPT Remote；
  • 已有自建 Agent 守护进程，还要接公司内部流程：自己做 App Server 桥接。

不要因为团队平时使用 Slack，就默认所有 Agent 都应该从 Slack 启动。聊天入口相同，不代表执行环境和会话状态相同。

自建常驻 Agent，App Server 才是正确的控制面

如果这个“全自动 Agent”不是 ChatGPT 桌面应用里的一个聊天，而是我写的服务：它从任务队列取工作、按照计划循环执行、可能运行数天，那么 Remote 就不再是完整答案。

这时更稳妥的结构是：

1
2
3
4
5
6
7
手机上的 Slack / Telegram
            ⇅
     消息桥接服务 Relay
            ⇅  stdio / Unix socket / 本机回环
       codex app-server
            ⇅
       Agent thread / turn

Codex App Server提供双向 JSON-RPC 接口。客户端可以创建或恢复 thread，开始新的 turn，在工作过程中 steer，并持续接收 Agent 消息、工具执行和任务状态事件。Agent 需要人回答时，可以发出 tool/requestUserInput；需要授权时，也有对应的审批请求。

Slack 或 Telegram 在这套架构里只是交互外壳。真正保存任务状态的是 Relay 和 App Server。Relay 至少要做好下面几件事：

App Server 事件 Relay 应怎样处理
turn/started 更新频道状态，不必每次都打扰人
Agent 消息与进度事件 聚合、限流，定期发送阶段摘要
tool/requestUserInput 发送高优先级问题，并把回复关联到原 request
审批请求 显示具体动作、影响范围与允许/拒绝按钮
turn/completed 发送结果、diff、测试与下一步摘要
失败或超时 告警，并保留恢复 thread 所需的标识

这里最容易低估的是关联关系。每条外部消息都需要知道自己属于哪个 threadId、turnId 和 requestId；按钮需要幂等，重复点击不能执行两次；等待人的问题需要过期时间，超时后 Agent 应该停止、采用安全默认值，或者转入待处理队列。

这也是为什么我不建议直接写一个脚本，把 Agent 输出原样转发到 Telegram。能把消息发出去，只完成了“门铃”；能把人的回答安全地送回正确一轮任务，才有了“对讲机”。

Hook 适合做门铃，不适合承担整套对话

Codex 的生命周期 Hooks可以在工具调用、权限请求、任务停止和会话结束等节点执行脚本；通知能力也可以在一轮结束时调用外部程序。

因此，用 Hook 调一个 Webhook，把“测试已经完成”或“任务失败”发送到手机，是低成本而实用的方案。

但 Hook 本身不是会话协议。后台 Hook 不会凭空开启新一轮对话，脚本也没有自动解决身份、线程恢复、问题应答和审批语义。把 Hook 不断扩展成双向机器人，最终还是会重新实现一套简化版 Relay。

我的边界是：

  • 只要完成和失败通知：Hook 或 CLI notification 足够；
  • 需要我回来继续同一个 Codex 聊天：Remote；
  • 需要外部聊天软件驱动自建 Agent：App Server + Relay。

不要把 App Server 直接暴露到公网

App Server 默认支持标准输入输出的 JSONL，也支持 Unix socket；WebSocket 传输仍属于实验能力。官方文档特别提醒，非本机回环地址如果没有额外认证并不安全，不应该直接暴露在共享网络或公网。

更安全的做法是让 Relay 和 App Server 位于同一台 Mac mini，通过 stdio、Unix socket 或 127.0.0.1 通信；Relay 只建立出站连接，接收 Slack/Telegram 平台经过签名验证的 Webhook。必须跨机器时，再使用 VPN、mesh 网络或受控 SSH 隧道。

除此之外，还应保留这些边界：

  • 只允许指定账号和频道控制 Agent；
  • 审批消息必须展示将要执行的真实命令或外部写入；
  • 高风险动作不能因为“来自我的手机”就永久免审；
  • 对进度消息做合并和节流，只有需要人时才强提醒；
  • 保存最小必要审计记录，同时避免把密钥、代码和终端输出完整复制到第三方聊天平台；
  • Agent 长期无人应答时进入安全停顿，而不是自己扩大权限继续尝试。

远程控制的价值是让人离开桌面，不是让安全边界也一起离开。

最后怎么选

如果今天就要给一台 Mac mini 上的 Codex 增加远程值守能力，我会按这个顺序做：

  1. 先启用 ChatGPT Remote，验证手机通知、继续对话、Queue、Steer 和审批是否已经覆盖日常需求；
  2. 只有通知不够时，再用 Hook 把少量关键事件发到现有告警渠道；
  3. 只有 Agent 已经是独立守护进程，才实现 App Server Relay；个人偏 Telegram 的轻量体验，团队偏 Slack 的身份、频道和审计能力；
  4. 原生 Slack 集成留给 Codex Cloud 的团队派单，不把它误当作本地会话接管工具。

一句话总结：个人远程值守选 Remote，团队云端派单选原生 Slack，自建无人值守 Agent 选 App Server 加聊天桥接，Hook 只负责敲门。

最好的接入方式，不是消息能到达最多平台，而是在 Agent 真正需要人时，用最少的中间层把人带回正确的任务、正确的轮次和正确的权限边界。

资料与口径

  • OpenAI：ChatGPT Remote，远程连接、移动端控制、通知、Queue/Steer 与安全边界
  • OpenAI：Mastering Codex Remote for Engineering，手机控制面与长任务工作流
  • OpenAI：Codex App Server，thread、turn、steer、用户输入请求、审批与传输协议
  • OpenAI：Hooks与Notifications，生命周期事件与单向通知能力
  • OpenAI：Codex in Slack，Slack 中创建 Codex Cloud 任务的适用边界
  • 查询日期：2026-08-15。Remote 可用范围、移动端入口、Slack 集成和 App Server 协议仍可能变化，落地前应重新核对官方文档。