Codex 2026-07-16 197 次浏览

动手做一个 Codex Web 控制台，远程让 Codex 继续为你打工

基于 Codex App Server 搭建移动端优先的远程 Web 控制台，讲清任务事件、审批、断线恢复、安全架构和最小实现闭环。

下班前把任务交给 Codex，回家路上用手机看进度、批命令、改方向。电脑留在公司，工作继续推进。

先说场景：人下班了，Codex 还没干完

假设下班前，你给 Codex 一个任务：

升级项目依赖，修复兼容问题，并运行全部测试。

这种任务很难在几分钟内结束。Codex 需要分析代码、修改文件、运行测试，中途还可能遇到测试失败、命令审批或者方案调整。

你当然可以继续守着终端，但更理想的方式是：让 Codex 留在公司电脑或远程开发机继续工作，自己直接下班。

这就是我们要做的东西：一个 Web Codex 远程控制台。

它不需要一开始就复制完整 IDE，只要先解决五个问题：

查看哪些电脑和项目在线；
查看 Codex 正在执行哪些任务；
实时接收计划、命令、Diff 和测试结果；
在手机上批准或拒绝危险操作；
随时追加要求、中断任务或继续历史对话。

问题随之而来：一个 Web 页面，怎样控制另一台机器上正在运行的 Codex？

答案就是 OpenAI 开源的 Codex App Server。

先记住一句话：

Codex SDK 让程序调用 Codex，App Server 让你开发自己的 Codex 客户端。

为了做这个 Web，先认识 App Server

App Server 可以理解为一个没有界面的 Codex 后端。

它负责运行 Codex 的核心能力：管理任务、调用模型、读取代码、修改文件、执行命令、控制沙箱、请求审批，以及持续输出执行进度。

开发者只需要在它上面增加自己的界面：

聊天窗口和任务列表
实时终端和代码 Diff
命令、文件与网络审批
模型、权限和连接设置
面向手机的远程控制页面

它不是一个新模型，也不是普通的聊天 API。

OpenAI 开放的不是 Codex 的一个按钮，而是按钮后面的整套控制系统。

App Server 的实现已经进入 OpenAI Codex 开源仓库。

官方协议、启动方式和完整事件列表可以直接查看：Codex App Server 官方文档。

为什么普通 API 不够？

Codex 最初主要运行在终端中。后来 OpenAI 开发 VS Code 扩展，需要从 IDE 界面驱动同一套 Agent，却不想重新实现模型调用、工具执行、会话管理和权限审批。

团队最初尝试把 Codex 做成 MCP Server，但很快发现：MCP 适合“调用工具”，不适合呈现一个完整、持续、可干预的 Agent 工作过程。

一个真正的 AI 编程客户端还要处理：

Codex 正在做什么，用户要实时看到；
命令输出要持续滚动；
文件修改要展示 Diff；
危险操作要暂停并请求批准；
任务要能保存、恢复和分叉。

于是 OpenAI 开发了面向富客户端的双向 JSON-RPC 接口，也就是 App Server。不同界面可以共享同一套 Codex Harness，而 App Server 负责把底层 Agent 事件转换成适合 UI 展示的消息。

CLI / IDE / 桌面端 / Web / 自定义客户端
                    ⇅
             Codex App Server
                    ↓
             Codex Harness
                    ↓
    模型、工具、终端、文件、审批、会话

三个概念，看懂它如何工作

Thread、Turn、Item 的关系

Thread：一个持续任务

例如“升级 Spring Boot 并修复兼容问题”，就是一个 Thread。

它可以被创建、恢复、分叉和归档。用户第二天回来，仍然可以继续同一个任务。

Turn：用户的一轮要求

一个 Thread 可以包含多轮 Turn：

Turn 1：先分析影响范围，不要修改代码
Turn 2：开始升级并运行测试
Turn 3：数据库驱动暂时保持当前版本

Codex 工作时，用户还可以追加要求或中断当前 Turn。

Item：任务中的具体事件

用户消息、Agent 回复、执行计划、命令运行、文件修改、测试结果和 MCP 调用，都是 Item。

简单理解：Thread 包含 Turn，Turn 包含 Item。

App Server 最关键的能力：双向交互

普通 API 通常是“你问，它答”。App Server 则会持续推送工作事件：

用户提交任务
→ Codex 更新计划
→ 执行命令并输出日志
→ 修改代码并更新 Diff
→ 请求用户审批
→ 用户允许
→ Codex 继续执行
→ 返回最终结果

而且服务端可以主动向客户端发起请求。

例如 Codex 准备运行数据库迁移测试，它可以暂停任务，让用户选择：

允许一次
本次任务允许
拒绝
取消任务

用户作出决定后，Codex 再继续。

普通模型 API 给你一个答案，App Server 给你整个工作现场。

SDK、App Server、MCP，怎么选？

方案	核心用途	典型场景
Codex Exec	一次性运行 Codex	Shell、CI 单次任务
Codex SDK	在程序里调用 Codex	自动修复、批量审查、后台工作流
Codex App Server	开发交互式 Codex 客户端	IDE、桌面端、Web 工作台
MCP	给 Codex 连接外部系统	GitHub、Jira、Figma、数据库

再看具体能力：

对比项	Codex SDK	Codex App Server
任务执行和连续对话	支持	支持
流式事件	常用事件	更完整、更适合 UI
任务历史	部分操作	完整管理
实时终端与 Diff	有限	完整支持
用户审批	以策略配置为主	双向审批协议
登录、模型与配置	部分支持	完整控制接口
Skills、Apps、MCP 管理	部分或未封装	支持
接入成本	低	较高

动手做第一版 Web 控制台

理解 App Server 之后，就可以回到我们的目标：让 Codex 在远程机器工作，再通过浏览器或手机控制它。

让 Codex 在远程机器持续工作，人通过浏览器或手机在关键时刻介入。

第一版不需要做成完整 IDE，五个模块就够了：

机器列表：显示公司开发机、个人电脑和测试服务器是否在线。
任务列表：展示执行中、等待审批、已完成和失败的 Thread。
任务详情：用时间线展示计划、命令、文件修改和测试结果。
审批中心：集中处理命令、文件、网络和 MCP 工具审批。
远程控制：追加要求、中断任务、恢复历史任务。

下面这张图展示了第一版控制台的核心入口：选择目标项目、查看最近任务、确认网关连接状态，并通过访问令牌保护远程入口。

按项目管理任务的 Web Codex 控制台

进入任务工作区后，控制台还可以继续展示全部历史任务和右侧运行详情：

这个界面的重点不是“像不像 IDE”，而是让用户随时回答三个问题：

Codex 现在做到哪里了？
有没有需要我处理的审批？
我是否需要改变它的方向？

项目源码已经开放

本文展示的控制台不是概念图，项目源码已经发布到 GitHub：

begincode/codex_web：Codex Remote Console

它采用移动端优先设计：Web 页面运行在 3100 端口，Node 网关运行在 8787 端口，并通过 stdio 管理 codex app-server。Codex 登录、配置和历史任务仍留在个人电脑上，浏览器只保存 HttpOnly 会话 Cookie。

最小启动流程：

codex login
npm install
cp .env.example .env
npm run dev:all

项目默认面向个人和私人 VPN 使用，不应把 Web 或网关端口直接映射到公网。具体访问口令、项目白名单和长期运行方式，请以仓库 README 为准。

Web 页面不要直连 App Server

远程 Codex Web 控制台架构

App Server 可以读取代码、修改文件、执行命令、使用本地凭证，也可能访问开发环境和外部系统。

因此，不要把 App Server 端口直接暴露到公网。

正式架构应该在浏览器和 App Server 之间加入自己的 Web 后端，由它负责：

用户认证与机器绑定
权限控制和多用户隔离
事件持久化与断线恢复
审批请求转发
操作审计和速率限制
App Server 进程管理

浏览器关闭后，Codex 继续执行；Web 后端继续保存事件。用户重新打开页面时，系统读取 Thread 历史并恢复实时状态。

浏览器不是长期任务的状态中心，服务端才是。

App Server 提供了 Agent Runtime，但不会替你解决正式产品的全部工程问题。

如果要上线团队使用的 Web 产品，还需要补齐：

用户认证、授权和多租户隔离
操作审计、密钥管理和任务队列
断线恢复、审批超时和并发控制
TLS、网络边界和最小权限策略

协议也会随 Codex 版本演进。开发客户端时，应基于当前版本生成类型：

codex app-server generate-ts --out ./schemas
codex app-server generate-json-schema --out ./schemas

升级 Codex 后重新生成 Schema，并进行兼容性测试。

有了 App Server，我们能做什么？

底层能力门槛确实降低了。Agent 循环、命令执行、文件修改、任务历史、实时事件和审批机制都已经具备。

但成熟产品仍然需要编辑器集成、上下文组织、低延迟体验、错误恢复、安全设计，以及对目标用户工作流的理解。

App Server 降低的是基础设施门槛，没有消灭产品门槛。

真正的机会，可能不是再做一个相同的 AI 编辑器，而是把 Codex 放进更具体的场景：

企业内部研发平台
遗留系统升级工具
自动化缺陷修复平台
远程 Agent 工作台
面向测试人员的工程客户端
面向非程序员的软件修改工具

最后

我们要做的并不是另一个复杂 IDE，而是一个很明确的工具：Codex 留在目标机器工作，人通过 Web 页面查看进度、处理审批并随时调整方向。

App Server 提供 Agent Runtime，Web 后端负责安全和状态，浏览器负责把关键过程交给人控制。

先把“任务列表、事件流、审批、追加要求、断线恢复”这个最小闭环跑通，再逐步增加 Diff、模型、Skills 和 MCP。这样做，比一开始复制完整 Cursor 更容易落地，也更容易验证真正的使用价值。

它最值得关注的地方，就是让 Coding Agent 脱离当前这块屏幕：

电脑在那边，工作在这里继续。

参考资料：