5月13日,OpenAI Codex 发布多项面向前端开发与并行任务管理的更新,核心动作包括:应用内浏览器(in-app browser)新增多视口断点测试能力,可在不同屏幕尺寸下自动遍历应用并截图验证,隐藏浏览器后测试速度提升 1-2 倍;注释(annotation)功能完成发送速度与 token 消耗双重优化;CLI 端 /side 与 /fork 分叉命令在 v0.130.0(5 月 8 日)中稳定可用,叠加 Codex App/Desktop 已支持的多窗口并行 + Git worktree 隔离 + 弹窗快捷键(Cmd+Shift+B),组成从"单线程会话"到"多线程并行操作"的完整工作范式。这是 Codex 自 2025 年 5 月以 codex-1 模型预览版起步以来,在桌面端体验与并行编排两个方向上最集中的一次升级。
应用内浏览器:多视口断点测试、关键时刻截图、隐藏加速
Codex 的应用内浏览器(in-app browser)最早作为前端调试的共享视图存在——Codex 与用户在同一线程内查看本地开发服务器的渲染页面,用户可以在 comment 模式下圈选元素直接留视觉评论(例如"这个按钮在移动端溢出,保持卡片高度不变修一下"),Codex 接收注释后直接修改代码并重新渲染。
5 月升级的核心是让 Codex 自己操作设备工具栏。具体能力包括:在不同视口尺寸(桌面、平板、移动)下自动加载页面、在响应式断点位置点击遍历应用流程、在长任务执行过程中自动捕获关键时刻截图并在本轮结束时一次性展示给用户。这把"前端响应式测试"从过去必须配 Playwright 才能跑的工作流,变成了应用内置原生能力。
提速 1-2 倍的实现路径是"隐藏应用内浏览器禁用动画"——Codex 在确认页面渲染状态的环节关闭过渡动画与 hover 反馈,减少等待时间。这条优化背后是过往的一个被多次反馈的问题:in-app browser 视口宽度受 Codex 侧边栏限制,容易在平板/移动断点被误判为桌面端 bug。新的多视口能力直接绕过了这一限制。
注释功能的优化同样重要。社区此前反馈较多的问题是:用户在 in-app browser 留下视觉注释后,Codex 进入 Plan 模式时有时会丢失注释上下文,或在响应中跳过注释处理。这次更新中,注释发送速度被加快,token 消耗减少,意味着浏览器视觉反馈可以更密集地嵌入到代码迭代循环中,而不必担心拖慢整体节奏。
/side 与 /fork:Codex 的多线程操作范式
并行操作能力是另一条独立但相关的升级线。Codex CLI v0.130.0(5 月 8 日)将 /fork 与 /side 两个分叉命令稳定下来,作为多线程工作流的核心原语。
两者的语义不同。/fork 完整克隆当前对话到新线程,获得全新的 thread ID,原对话不受影响,适用于"我想在这条线程的某个节点尝试另一条路径,但不想丢掉原来的进展"。/side 则开启一个临时旁路对话,语法上可以直接附加内联文本(例如 /side 检查这个方案是否有明显风险),专门为"主任务进行中,临时追问一个不希望污染主线程的问题"设计。/side 结束后可立即回到主线程,/fork 则保留两条独立分支供后续切换。
在 Codex App/Desktop 层面,这两个 CLI 命令叠加了三个 GUI 能力:可同时打开多个完整窗口处理不同任务、为弹窗 Codex 入口设置全局快捷键、为不同任务自动创建 Git worktree 实现文件级隔离。三者组合形成的实际工作流是:主线程跑大重构,通过 /side 临时问"这个 import 改完会破坏哪些下游",同时另开一个独立 Codex 窗口在 Git worktree 隔离环境下跑响应式 UI 调试,所有任务并行推进且不互相干扰。
OpenAI 开发者关系工程师 dominik kundel 5 月公开的使用建议中明确了这套范式的产品意图:不必把 Codex 当作单线程 Chat,而应当作可同时驾驭多个并行线程的工作站。
在 Claude Code、Cursor、Playwright 等竞品中的位置
把 Codex 这次升级放在 2026 年中编程 Agent 工具竞争格局中看,差异化在前端响应式测试 + 并行编排两个具体场景上。
Claude Code + Cowork(Anthropic):Claude Code 是 Codex 在 CLI 层面的直接对手,2026 年 4 月发布的桌面端 Cowork 把同一引擎扩展到了非技术用户。Claude Code 的 Computer Use 也具备屏幕识别 + 操作能力,但以单游标、前台运行为主——Codex 这次的多视口断点测试是 in-app browser 内置能力,不需要切换到 Computer Use 模式;而 Cowork 的子 Agent 并行属于"用户描述任务后系统决定何时分裂",Codex 的多窗口 + /side 则把并行控制权显式交给开发者。两者在"开发者主导"和"系统主导"两条路径上对位。 Cursor / Windsurf:IDE 集成型 Agent,优势在编辑器内零切换体验,但响应式 UI 测试通常仍需打开外部浏览器或 Playwright,无原生 in-app browser。Codex App 的 in-app browser + 注释 + 多视口三件套是 IDE 集成 Agent 目前没有完整对位的能力。
Playwright + 通用 Agent:Playwright 长期是响应式 UI 自动化的事实标准,Codex 此前的官方推荐工作流也是接入 Playwright Skill。这次 in-app browser 升级的实际效果是把 Playwright 在"打开应用 → 切换断点 → 截图比对"这一步的能力直接内置到 Codex 桌面端,对一部分中小复杂度的前端任务,Playwright 已经不是必选项。
Codex Chrome Extension:Codex 5 月还同步推送了 Chrome 扩展,补足了 in-app browser 不支持登录态、Cookie、扩展、现有 Tab 的限制——需要登录后操作的场景由扩展承担,本地开发服务器与公开页面由 in-app browser 承担,两条路径互补而非替代。
局限、平台限制与待观察问题
这次升级存在几项明确局限。视口限制的根源未完全解决:虽然多视口测试是新能力,但 in-app browser 仍然受限于 Codex 桌面端侧边栏的物理宽度,部分用户在 GitHub 上反馈希望 in-app browser 能够"detach"成独立窗口,目前 BrowserUseExternal 仍是 feature flag 状态。Computer Use 平台覆盖不均:背景 Computer Use 4 月首发仅在 macOS 全量可用,Windows 与 EU/UK 用户仍需分阶段开放,这意味着同一团队在不同操作系统/区域的同事能用到的 Codex 能力不一致。注释 + Plan 模式的稳定性:社区在 5 月发现的一个 bug 是注释截图可以正常出现在线程内,但 Plan 模式下 Codex 偶尔会忽略注释直接跳过,新一轮的注释速度优化是否同步修复了这个稳定性问题,目前没有公开数据。/side 在 GUI 端的可见性:目前 /side 主要作为 CLI 命令呈现,Codex App 的可视化分叉入口仍弱,用户需要在 CLI 与 GUI 间切换感知分叉状态。
从产业脉络看,Codex 这次升级的核心信号不是"加了几个功能",而是"把开发者的真实并行工作流变成产品原语"。过去一年里,Cursor、Claude Code、Windsurf、Codex 都在不同方向尝试解决同一个问题——AI 编程从"单条 prompt 单次输出"演化为"多任务并行、长流程持续、视觉反馈密集"的真实工作方式。Codex 在 5 月 8 日 CLI v0.130 + 5 月中下旬 App 应用内浏览器升级 + Chrome 扩展 + Computer Use 背景化的组合中,押注的是开发者愿意为"显式控制多个并行 Agent"付费,而不只是为"更聪明的单 Agent"付费。这一押注在 2026 年下半年面对 Claude Code Cowork、Cursor Agent、OpenClaw 等竞品的回合中能否守住,是接下来 6 个月最值得跟踪的赛道变量。