Three Ways Codex Can Use a Computer

作者：jason (@jxnlco)

原文链接：https://x.com/jxnlco/status/2066970432855581052

这篇文章讲的是 Codex 操控你电脑的三条入口：Computer Use、Chrome 扩展和应用内浏览器。

三者有重叠，恰是这种重叠最容易让人困惑。

作者把每条入口的安装、触发、适用场景、信任边界都讲清楚了，并反复强调一个核心判断：

能用结构化插件或 MCP 时，就别用可视化操作。

可视化操作的价值，正好落在结构化工具失效的边界上。

更值得读的是大量真实用例：

盯着 Amazon 客服追回退款、给 Strudel Composer 重写和声、长期巡检 Twitter DM、用应用内浏览器做设计批注、Appshot 把眼前内容「指」给 Codex 看。这些例子让抽象的「三条入口」落到具体的工作流里，便于照搬。

末尾还附了关注路径，方便跟踪这三条快速演进的入口。整体偏操作手册，读完可直接动手配置。

Codex 使用电脑有三种方式：

Computer Use、Chrome 扩展、应用内浏览器。

它们彼此重叠，重叠的程度恰好让人迷惑。

读完本文，你会知道如何安装并触发这三者、各自适合什么时候用、Appshots 和 Developer mode 如何把它们串起来，以及该往 AGENTS.md 里写点什么，让 Codex 自己选对入口。

话虽如此，只要条件允许，优先用插件或 MCP。

一个 Slack 插件取回某条讨论的精度，远胜在 Slack 里点来点去；

一个 GitHub 插件产生的动作，也比驱动网站更易审查。可视化控制最有用的地方，正是结构化工具失效的那道边界。

1. 一切都是 @Computer

Computer Use 是三种入口里覆盖面最广的一种。它让 Codex 在 macOS 和 Windows 上看见并操作图形界面——操作窗口、菜单、键盘输入、剪贴板，作用范围限于你授权的应用。

它通常也最慢。

一个结构化插件能直接调用 API；

Computer Use 得先看界面、决定点哪里、等应用响应、再检查下一个状态。

这个视觉循环要花时间，但代价换来的是：

Codex 能搞定那些完全没有可用 API 的应用。

在 macOS 上，慢未必意味着打扰。Computer Use 可以在后台操作已授权的应用，你照常用电脑的其他部分。我自己经常一边用 Codex，一边打开某个应用，才意识到 Codex 一直在安静地跑某个 workflow。

视你电脑上装了什么、授权了什么，这可能包括 Spotify、XCode、系统设置、iOS 模拟器，甚至 iPhone Mirroring 来控制你的 iPhone。它也能在某个 workflow 跨多个应用时来回切换。

适合用它的场景，是任务依赖：

安装方法：

在 Codex 里打开 Settings > Computer Use，点击 Install。

触发方法：提及 @Computer，或明确要求 Codex 使用 Computer Use。随着模型变强，它将能在需要时自行调用。

先试几个例子：

我最喜欢的一个例子，源自一个被偷的包裹。Amazon 告诉我接通客服大约要 25 分钟。我给一个 Codex 线程开了 Computer Use，让它每五分钟检查一次聊天，客服一出现就改成每分钟一次，并尽力把退款要回来。我洗完澡回来，退款已经到账。

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

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.

我也把 Computer Use 当作一个「最后一公里」用在基本结构化的 workflow 里。在一条发布视频里，Codex 能从 Slack 读反馈、改代码、渲染新视频，但那个线程可用的 Slack 集成没法上传文件。Computer Use 点了一下 Add file，补上了那一步缺口。

它也是三者里最大的信任边界。一次只给它一个明确的应用或流程。任务用不到的敏感应用随手关掉，审查权限弹窗，并在涉及财务、账户、支付、凭证、隐私和系统安全变更时，全程在场。

2. @Chrome 适合多标签页与身份认证

Codex 的 Chrome 扩展让 Codex 访问你已登录的 Chrome 状态。任务依赖你的账户、cookie、浏览器配置或已认证标签页时，就用它。

适合这类工具里的工作：

安装方法：

在 Codex 里打开 Plugins，添加 Chrome，跟着设置流程走。Codex 会引导你安装 Codex Chrome 扩展并批准 Chrome 的权限。扩展显示 Connected 后，开一个新线程。

触发方法：提及 @Chrome，或明确要求 Codex 使用你已登录的 Chrome 浏览器：

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 能把同一个任务的多个标签页关联起来——在一个里读上下文，与另一个对比，再到第三个里继续 workflow。

Computer Use 也能可视化驱动浏览器，但 Chrome 把工作理解成一个浏览器 workflow，而非一串屏幕坐标。

在最近一个线程里，我把一个已打开的 Strudel Composer 标签页交给 Codex，让它把音乐做得更有意思。

Chrome 把选中的标签页和页面的 WebMCP 工具给了它。Codex 检查了这首曲子，重写了和声与四分钟的结构，改了 tempo，保存了这条 track，让它继续播放。

它不用为每个控件在屏幕上瞎找，因为 Chrome 把标签页上下文和页面暴露的结构化能力合在了一起。

我用它维护一条长期运行的 Twitter 线程，指令大致是：

每天用 Chrome 检查我的 DM，读相关新闻，找找我该知道的反馈或提及。把任何长期有用的内容加进我的 vault。不要发帖，不发消息。

真正有意思的是这条线程能在时间里反复回到同一份已登录的工作，把找到的东西连到本地文件，留给我一个可审查的结果。

信任边界很重要。

网站可能把 Codex 的点击、表单提交和消息，当作你本人的操作。页面内容也是不可信输入。把后果重大的步骤保持显式：研究、导航、起草自动进行；发送、发布、购买或提交之前，要求你亲自审查。

如果整个任务都在浏览器里，优先用 Chrome，而非 Computer Use。Chrome 有任务所需的浏览器原生上下文，又无需开放桌面的其他部分。

3. 应用内 @browser，给你正在构建的网站

应用内浏览器是一个住在 Codex 线程里的浏览器。你和 Codex 共享同一个渲染好的页面，所以它特别适合构建和调试 web 应用。

我通常会从这里开始：

关键约束是隔离。

应用内浏览器不用你日常的浏览器配置、cookie、扩展、已登录会话或已有标签页。任务需要账户时，这是限制；任务不需要时，这是有用的边界。

设置方法：在 Codex 里打开 Plugins，添加 Browser 插件，启用它。

触发方法：在 prompt 里提及 @Browser，或明确要求 Codex 使用应用内浏览器：

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 能改代码、操作页面、检查渲染状态、截图，并在修复后重复这套流程。

我最喜欢的是批注。

审查本地应用时，我可以直接点某个元素或框选一块区域留评论。

样式控制还能让我预览并发出关于文字、字体、间距、颜色更精确的反馈。

我习惯把它和语音输入、steering 结合：我审页面、留评论、在 Codex 处理的同时排更多反馈。页面本身就成了 spec。

这对设计工作尤其好用。

我常让 Codex 把一个想法、研究资料或项目状态，变成一个单文件 index.html，再在应用内浏览器里打开。与其在另一个 prompt 里描述整套设计，我直接在实际页面上批注：「这个层级反了」「让这个别那么像卡片」「这些控件需要更多空间」「全局用这套字号比例」。

Codex 带着相关截图和元素上下文收到评论，改文件，再把同一页面重开一遍再来一轮。

为这份项目简报创建一个单文件 index.html，并在应用内 @Browser 里打开。

这个循环，比来回传截图和文字描述更接近「和设计师在同一块画布上协作」。

应用内浏览器也适合作为混合 workflow 的起点。在另一个线程里，我在应用内浏览器里打开了一条 X 帖子，让 Codex 调查这场讨论。可见的页面确定了我说的是哪条帖子；Codex 随后切到 Twitter CLI，取回了 38 条回复，包括浏览器视图里藏起来的嵌套回复。

这就是「最小入口」原则在实践：用浏览器看屏幕上的上下文，再用结构化工具做更深的取数。

这里有个权衡。让应用内浏览器成为好开发面的那种隔离，也意味着它不该拿来和 Google 登录、passkey 或依赖你浏览器扩展的网站较劲。身份重要时，转向 Chrome。

Appshots

Appshot 并非 Codex 操控电脑的第四种方式。它是把 Codex 指向你眼前已有的上下文的方式。

在 Mac 上，同时按下 CMD+CMD 两个键，捕捉最近的窗口。Codex 把一张图片和任何可用文字附到一个线程里。你可以对一段报错、一封邮件、一份设计、一个设置面板或一个不熟的表单做 Appshot，然后直接说：

我最容易记住的心智模型是：

Appshots 是你「指向」电脑上某样东西的方式。Browser、Chrome 和 Computer Use 是 Codex「行动」的方式。

Appshot 目前从 macOS 上的 Codex app 创建。它捕捉最前面的窗口，而非整个桌面，这让它成为一种提供聚焦上下文、又不必交出应用控制权的有用方式。

如何跟进这些工作

这些入口演进很快。如果你想拿到有用的细节，而不想等一篇大发布回顾：