Codex Remote 正式可用：移动端审批变成路由控制面问题

OpenAI 6 月 25 日的 Codex 更新让 Codex Remote 进入正式可用阶段。它的重要性不只是“可以用手机操作 Codex”，而是给 coding-agent 团队增加了一个新的运营边界：开发者可以在 ChatGPT 移动端启动或继续 Codex 任务，在配对的 Mac 或 Windows 主机上查看进度并批准动作。OpenAI 同时表示，Remote Control 现在采用每台 iOS 或 Android 设备与每台主机之间的一对一 QR 认证配对；新的 DigitalOcean plugin 还能创建 Droplet、配置 SSH 访问，并把它接入 Codex App 作为远程工作区。

这组变化改变了路由问题。agent 不再只是选择一个模型 endpoint。它会跨过手机、笔记本、云主机、plugin 目录、远程 shell 和人工审批界面。

发生了什么

OpenAI 的 Codex changelog 中有两个 6 月 25 日更新值得 operator 关注。第一，Codex Remote 达到 general availability。该功能允许用户通过 ChatGPT 移动端控制 Codex 工作，包括在已连接的 Mac 或 Windows 主机上启动或继续任务，并在离开工作站时批准动作。

第二，Remote Control 现在要求每台移动设备与每台主机之间使用认证的一对一 QR 配对。OpenAI 说明，自 2026 年 6 月 8 日以来使用过的连接会保持配对，更早且不活跃的连接需要重新配对。该更新也要求团队在连接前升级 ChatGPT mobile app 和 Codex App。

同一次更新还引入了 DigitalOcean plugin。它可以创建 Droplet、配置 SSH 访问，并连接到 Codex App 作为远程工作区。这让远程执行不再只依赖手工准备好的开发机，而更像一条可临时创建的云端 host lane。

为什么对 AI 工程团队重要

远程 coding agent 会制造一种 split-brain 运营模式：意图可能来自手机，代码执行在桌面或云 VM，模型调用可能经过 gateway，审批又发生在另一台设备的 session 中。如果这些路径没有被一起治理，成本归因和安全审查都会变得模糊。

对工程团队来说，GA 标签意味着 Codex Remote 正从实验功能变成可能进入日常开发流的能力。这带来三个实际问题：

• 哪些 host 允许运行远程 Codex session，凭据由谁负责？
• 哪些动作需要本地审批、移动端审批，哪些动作可以不审批？
• 当移动端用户驱动配对工作站或新建 Droplet 执行任务时，成本应该归到哪个用户或项目？

DigitalOcean plugin 又增加了一层变量。新的 Droplet 适合隔离实验，但也会产生云资源、SSH 材料和网络出口路径。团队需要生命周期策略：谁可以创建、允许什么镜像、host 存活多久，以及日志如何回连到原始用户。

路由与运维视角

对路由层来说，Codex Remote GA 的信号是：coding-agent 流量应该按 session 建模，而不是按孤立 completion 建模。一个任务可能包含移动端控制事件、host 执行、tool call、plugin 创建资源、模型调用和审批决策。路由策略需要足够的上下文，判断请求属于交互式桌面 lane、远程云 host lane，还是需要敏感审批的 lane。

一个实用 operator 框架是把它拆成四个平面：

• Identity plane: 移动端用户、配对 host、组织、项目和云工作区必须先关联，模型支出才可信。
• Execution plane: Mac、Windows 与临时 Linux host 需要不同的 sandbox、网络和 secret 策略。
• Approval plane: 移动端审批应该作为一等治理事件记录，而不能等同于本地终端确认。
• Cost plane: 模型 token、plugin 动作、云 VM 时间、失败和重试的远程 session，都应该能回收到同一个用户或项目账本。

这也是 multi-provider routing 变成治理问题的地方。团队可能希望低风险远程规划走更快、更便宜的模型，最终补丁走 frontier coding model，而触碰基础设施或 secret 的命令必须进入更严格的审批 gate。远程控制界面让这种策略对用户可见，但真正的执行仍需要落在 operator stack 中。

TheRouter 用户应关注或尝试什么

正在评估 Codex Remote 的 TheRouter 用户，应该先做 inventory，而不是先跑模型 benchmark。记录哪些 Codex Remote routing session 是本地的、移动端驱动的、云端 host 的；每个 session 使用哪个 provider/model tier；哪些审批发生在开发者主工作站之外。可以先用 routing and governance overview 作为宽口径策略参考，再用 model catalog 对照允许的模型层级，然后再把远程执行开放给更大团队。

可执行检查包括：

• 把 QR 配对的移动设备和连接 host 视为同一个受治理 session，统一做 billing 与 audit。
• 在 routing policy 中把远程云工作区与个人工作站分开，因为它们的网络和凭据风险不同。
• 用 gateway-side usage records 比较远程 session 与普通本地 Codex session 的成本，再决定是否大规模放开。
• 对 plugin 驱动的基础设施创建保持显式 review，直到团队具备资源清理和 owner 归因流程。

更大的经验很直接：当 coding agent 可以从手机驱动桌面或新建 VM 执行任务时，路由策略必须包含 session identity、host trust 和 approval provenance，而不只是“哪个模型回答了 prompt”。