Codex 悄悄加了 remote-control 模式：手机遥控你的编码 Agent

产品更新

OpenAI 在 Codex 仓库新增了 `codex remote-control` 子命令，作为启动无头、可远程控制 app-server 的简化入口。这意味着 Codex 正式补上了 Claude Code 早就有的那块拼图——把编码 Agent 从工作站解绑，搬到手机和浏览器上。

一句话讲清楚

OpenAI 给 Codex CLI 偷偷加了个新子命令：codex remote-control。官方 commit message 写得很克制——"Added codex remote-control as a simpler entrypoint for starting a headless, remotely controllable app-server."

翻译一下就是：以后你不用人坐在工作站前，也能让 Codex 干活了。手机、浏览器、甚至 Apple Watch，都能成为遥控器。

这个功能目前还没进官方公告，是社区在翻 Codex 仓库 commit 时挖出来的。linux.do 上已经有人开帖讨论，Reddit r/codex 几周前就在追这条线索——从最早 "remote control coming soon" 的 PR 痕迹，到现在 remote-control 子命令真正落地，节奏其实不慢。

Codex CLI 在终端启动 remote-control 模式的示意图

这是补 Claude Code 的课

要理解这个更新的分量，得先看 Anthropic 那边发生了什么。

Claude Code 在去年底上线了 remote control：本地跑一个 Claude CLI 会话，手机 App 能直接接管——查看 diff、批准权限、发新指令、甚至语音输入。核心场景是"我在地铁上突然想到一个改动，掏出手机让 Agent 去跑，回到家代码已经写完在等我 review"。

这个范式一旦体验过就回不去了。编码 Agent 本来就是个长时间运行的异步任务，盯着终端看它打字纯属浪费人生。Claude Code 把交互从"同步终端"解耦成"异步审阅"，是过去一年 AI 编码工具里少有的范式级改动。

Codex 之前一直没跟上。Codex CLI 强在跟 ChatGPT 账号体系打通、强在 GPT-5 系列模型的代码能力，但形态上还是死死绑在终端里。社区里抱怨过很多次："为什么 Claude Code 能遥控，Codex 不行？"

现在，补上了。

remote-control 到底是个什么东西

从 commit 透露的信息和代码改动看，codex remote-control 本质上是启动一个 headless app-server——也就是不带 TUI 界面的 Codex 服务进程。

几个关键点：

  • Headless：不占用终端，可以放在后台、放在远程机器、放在云沙箱里
  • App-server：暴露一套可被外部调用的接口（推测是 WebSocket 或类似的长连接协议），用来接收指令、推送状态
  • Remotely controllable：意味着有配套的客户端会跟它对话——大概率就是已经在路上的 Codex 桌面 App 和移动端

之前 Codex 仓库里就有过 app-server 相关的代码，但启动方式比较绕，需要搭参数。这次 remote-control 的定位是 "a simpler entrypoint"——把那些参数封装成一个开箱即用的命令。

大致用法应该是这样：

# 在你的开发机上启动一个可远程控制的 Codex 实例
codex remote-control

# 之后从手机 App / 浏览器连进来
# 同一个 ChatGPT 账号下自动配对

注意这里的拓扑：Codex 进程跑在你自己的机器上（能访问你的代码仓库、你的环境变量、你的 git），手机端只是个瘦客户端，负责显示和发指令。这跟"把代码上传到云端让 OpenAI 跑"是完全两回事，对企业用户友好得多——代码不出本地。

几个能想到的真实场景

这功能听起来花哨，但实际价值是什么？我想了几个开发者会真用上的场景：

场景一：长任务监督。让 Codex 跑一个大重构、迁移一个老模块，预计要四十分钟。以前你得守在电脑前批准它每一步的权限请求。现在去开会，手机上叮一声——它问你要不要执行 rm -rf node_modules，你点个允许，继续开会。

场景二：跨设备接力。早上在公司机器上让 Codex 开始干一个 feature，下班路上手机查看进度、追加要求；回到家用平板继续 review diff，最后在自己的台式机上 merge。整个会话状态一致。

场景三：云沙箱组合。Reddit 上有人提到，remote-control 配合云沙箱（cloud sandbox）使用——Codex 进程跑在云端隔离环境里，你从任何设备都能连过去操作。这对那些不想让 Agent 直接在本地搞破坏的人来说是刚需。

场景四：团队共享 Agent。一个 headless 的 Codex 服务理论上可以让多人接入（权限模型怎么设计另说）。一个值班 Agent，谁都能调度，这个想象空间不小。

跟 Claude Code 对比，差距在哪

说实话，Codex 这次是"追上"，不是"超越"。Claude Code 的 remote control 已经迭代了几个月，踩过的坑不少：

  • 移动端能不能跑 /clear 这类斜杠命令（早期版本不行，社区抱怨过）
  • 能不能从手机停止 Agent、查看上下文使用量（也是一开始缺的）
  • 通知系统怎么设计，权限批准的延迟体验

这些都是 Codex 接下来要面对的工程细节。从命令命名（remote-control 这种朴素的英文短语）和"simpler entrypoint"的措辞看，OpenAI 这次走的是稳扎稳打路线，先把 server 端搞稳，客户端慢慢迭代。

另一个值得关注的差异是生态打通。Claude Code 的 remote control 严格绑在 Anthropic 自家 App。Codex 这边，因为 app-server 是相对开放的协议层，理论上社区可以做第三方客户端——已经有人在用 happy.engineering 的 Happy CLI 工具做类似调度，未来可能出现专门为 Codex remote-control 优化的第三方面板。

一些还没揭晓的问题

现在能确认的信息止于 commit。几个关键问题还要等正式发布才知道答案：

  1. 认证模型：手机端怎么和本地 server 配对？走 ChatGPT 账号 OAuth？还是生成一次性 token？
  2. 网络穿透：如果开发机在公司内网、手机在外面，怎么连？需不需要中继服务？（Claude Code 是走 Anthropic 自己的中继）
  3. 离线降级：server 断线后会话状态保留多久？
  4. 多 session 管理：能不能同时挂着五个 Codex 实例分别干不同的活？

这些问题的答案直接决定了 remote-control 是"玩具"还是"生产力工具"。

写在最后

AI 编码 Agent 这一年的演进路径越来越清晰：从"在 IDE 里 tab 补全"，到"在终端里跟你聊天写代码"，再到现在"在后台异步干活，你只负责审阅"。每一步都是把人从循环里往外拨。

codex remote-control 这个 commit 看起来不起眼，但它代表 Codex 正式踏进第三阶段。等正式发布、等手机端 App 上线，开发者的工作流会再次被改写一次。

顺带一提，OpenAI Hub 已经支持 GPT-5 系列模型的 API 调用，国内直连兼容 OpenAI 格式，跑 Codex CLI 的开发者切个 base_url 就能用上。等 remote-control 正式 GA，我们再补一篇上手实测。

参考来源