Codex 使用电脑的三种方式：Computer Use、Chrome 扩展和内置浏览器

Jason 在 X 上整理了一篇关于 Codex 电脑操作能力的长文，核心问题很实用：Codex 现在可以通过 Computer Use、Chrome 扩展和内置浏览器三种方式“使用电脑”，但它们的边界容易混在一起。

简单说：

• 能用插件或 MCP 解决时，优先用结构化工具。
• 需要操作桌面应用、系统设置或没有 API 的界面时，用 @Computer。
• 任务依赖你已经登录的 Chrome、账号状态、Cookie 或多个标签页时，用 @Chrome。
• 正在开发网页、调试本地页面、检查响应式布局或做视觉反馈时，用 @Browser。

可视化控制最适合放在结构化工具够不到的边界上。比如 Slack 插件通常比让 Codex 去点 Slack 页面更精确；GitHub 插件产生的动作也比驱动网页更容易检查。只有当 API、插件或 MCP 不能覆盖最后一步时，才让 Codex 去看屏幕、点按钮。

原帖：https://x.com/jxnlco/status/2066970432855581052

1. 用 @Computer 操作桌面和原生应用

Computer Use 是三种方式里范围最宽的一种。它让 Codex 在你批准的 macOS 或 Windows 应用里观察图形界面，并通过窗口、菜单、键盘、剪贴板等方式完成操作。

它通常也是最慢的。结构化插件可以直接调用 API；Computer Use 需要看界面、判断该点哪里、等待应用响应，再检查下一步状态。这个视觉循环有成本，但好处是它可以处理那些没有可用 API 的软件。

在 macOS 上，“慢”不一定意味着打扰。Computer Use 可以在被授权的应用里后台工作，你仍然可以继续使用电脑的其他部分。它能处理的对象取决于你安装并授权了哪些应用，可能包括 Spotify、Xcode、系统设置、iOS 模拟器，甚至 iPhone Mirroring。

适合使用 @Computer 的任务：

• 原生桌面应用，例如 Spotify、财务软件、设计工具；
• iOS 模拟器、iPhone Mirroring 或其他只能通过 GUI 操作的流程；
• 系统设置或应用设置；
• 没有插件、MCP 或 API 的数据源；
• 需要在多个桌面应用之间切换的流程；
• 结构化集成已经完成大部分工作，但最后缺一个界面动作。

安装方式：

1. 打开 Codex 的 Settings。
2. 进入 Computer Use。
3. 点击 Install，按提示完成授权。

触发方式：

1

Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.

1

Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.

原文里有一个很能说明边界的例子：Jason 曾经让 Codex 处理 Amazon 被盗包裹的客服等待。Amazon 提示大约要 25 分钟才能接入客服，他让 Codex 每 5 分钟检查一次聊天窗口，客服出现后改成每分钟检查，并尽量完成退款沟通。等他回来时，退款已经完成。

还有一种常见用法是“最后一公里”。例如 Codex 可以通过 Slack 读取反馈、修改代码并渲染视频，但当前线程里的 Slack 集成不能上传文件。这时 Computer Use 只需要点击 Add file，完成最后那个结构化工具缺失的动作。

安全边界也要更严格：Computer Use 的权限范围最宽，最好一次只给它一个明确应用或流程。涉及财务、账号、付款、凭据、隐私和系统安全的动作，要保持人在场，并检查权限提示。

2. 用 @Chrome 处理登录态、多标签页和账号相关任务

Codex Chrome 扩展让 Codex 使用你已经登录的 Chrome 状态。只要任务依赖账号、Cookie、浏览器资料、现有标签页或浏览器扩展，就更适合用 @Chrome。

适合使用 @Chrome 的任务：

• Gmail、LinkedIn 等需要登录的网站；
• Salesforce、客服后台或内部控制台；
• 公司内部仪表盘；
• 需要跨多个已登录网站做研究；
• 表单依赖你的账号、Cookie 或浏览器扩展。

安装方式：

1. 打开 Codex 的 Plugins。
2. 添加 Chrome。
3. 按提示安装 Codex Chrome 扩展并批准权限。
4. 看到扩展显示 Connected 后，开始一个新线程。

触发方式：

1

Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting.

Chrome 任务会在标签页组里运行，这能把同一个 Codex 线程相关的页面收在一起。和内置浏览器不同，Chrome 扩展使用的是你的真实浏览器身份，所以能力更强，也更敏感。

Chrome 的另一个优势是多标签页控制。它可以在一个标签页读取上下文，在另一个标签页比较信息，再到第三个标签页继续处理。Computer Use 也能视觉驱动浏览器，但 Chrome 更像是以“浏览器工作流”的方式理解任务，而不是一连串屏幕坐标。

原文提到一个 Strudel Composer 的例子：Jason 把一个已经打开的音乐创作标签页交给 Codex，让它把音乐做得更有意思。Chrome 给了 Codex 当前选中的标签页和页面提供的 WebMCP 工具，Codex 检查作品、重写和声与四分钟结构、修改速度、保存曲目，并让它继续播放。它不需要视觉寻找每个按钮，因为 Chrome 可以把标签页上下文和页面暴露的结构化能力结合起来。

长期任务也适合 Chrome。例如可以让 Codex 每天用 Chrome 检查 X 私信、相关新闻和反馈，把值得长期保存的信息加入本地知识库，但明确要求不要发布或发送消息：

1
2
3

Every day, use Chrome to check my DMs, read relevant news, and look for
feedback or mentions I should know about. Add anything durable to my vault.
Do not post or send messages.

这里真正重要的不是 Codex 能打开 X，而是同一个线程可以持续回到同一组登录态任务里，把看到的信息连接到本地文件，并留下可审查的结果。

Chrome 的信任边界同样要清楚：网站会把 Codex 的点击、提交、发送消息视为你的行为；页面内容本身也可能是不可信输入。比较稳妥的做法是允许它自动研究、导航和起草，但发送、发布、购买、提交之前必须由你确认。

如果整个任务都在浏览器里，而且需要登录态，优先选 Chrome，而不是 Computer Use。

3. 用 @Browser 开发和调试网页

内置浏览器是 Codex 线程里的浏览器。你和 Codex 看到的是同一个渲染页面，所以它特别适合网页开发、视觉调试和设计反馈。

适合使用 @Browser 的任务：

• 本地开发服务器；
• 本地 HTML 或文件预览；
• 不需要登录的公开页面；
• 复现视觉 bug；
• 检查响应式布局；
• 对页面元素留下设计反馈。

它最重要的约束是隔离：内置浏览器不使用你的正常浏览器资料、Cookie、扩展、登录会话或现有标签页。任务需要账号时，这是限制；任务不需要账号时，这反而是清晰的安全边界。

安装方式：

1. 打开 Codex 的 Plugins。
2. 添加 Browser 插件。
3. 启用它。

触发方式：

1

Use @Browser to open vite app on <http://localhost:3000/>, reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths.

这个入口最适合形成紧密反馈循环：Codex 修改代码、操作页面、检查渲染状态、截图，再根据结果继续修。

原文中特别强调了“标注”能力。做本地应用评审时，你可以直接点击某个元素或框选区域并留言，也可以对文字、字体、间距、颜色给出更具体的反馈。Codex 收到评论时，同时拿到相关截图和元素上下文，然后修改文件并重新打开同一页面。

对于设计工作，可以把一个想法、研究材料或项目状态交给 Codex，让它先生成一个单文件 index.html，再用内置浏览器打开。相比用另一段提示词重新描述整个设计，你可以直接在页面上标注：

1
2

Create a single-file index.html for this project brief and open it in the
in-app @Browser.

这样页面本身就变成了规格说明。

内置浏览器也适合做混合流程的起点。原文举了一个 X 帖子的例子：先在内置浏览器打开帖子，让 Codex 确认你指的是哪一条；然后切换到 Twitter CLI 拉取 38 条回复，包括浏览器界面隐藏的嵌套回复。这就是“用最窄的表面建立上下文，再用结构化工具深入检索”。

但如果任务卡在 Google 登录、Passkey、浏览器扩展或账号状态上，就应该从内置浏览器切到 Chrome。

Appshots：指向上下文，不负责执行

Appshots 不是第四种电脑控制方式，而是把你眼前的上下文交给 Codex 的方法。

在 Mac 上，可以按两次 CMD 捕获最近的窗口。Codex 会把图像和可用文本附加到线程里。你可以对错误提示、邮件、设计稿、设置面板或陌生表单做 Appshot，然后告诉 Codex你想让它处理什么。

一个好记的模型是：

Appshots 负责指出你电脑上的东西；Browser、Chrome 和 Computer Use 负责行动。

Appshots 当前从 macOS 的 Codex app 创建，捕获的是最前面的窗口，不是整个桌面。这让它适合提供聚焦上下文，而不必直接授予应用控制权。

怎么选择

如果要把这三种方式放进日常工作流，可以按下面顺序判断：

1. 先看有没有插件、MCP、CLI 或 API。能结构化完成，就不要让 Codex 去点界面。
2. 如果需要操作桌面应用、系统设置、模拟器或多个本机应用，用 @Computer。
3. 如果任务在浏览器里，并且依赖你的登录态、Cookie、扩展或多标签页，用 @Chrome。
4. 如果任务是网页开发、公开页面检查、本地预览或设计标注，用 @Browser。
5. 如果只是想告诉 Codex“看这个窗口”，先用 Appshots 提供上下文，再决定下一步用哪个入口。

这些入口的差别不只是功能差别，也是信任边界差别。越接近你的真实账号和桌面环境，就越应该把目标说清楚，把不可执行的动作写明白，并在提交、发送、付款、发布前保留人工确认。