OpenAI 给 Codex 增加了一个 Chrome 扩展。
核心想法很直接：当任务需要用户已经登录的浏览器状态时，Codex 可以使用 Chrome。也就是说，它可以进入那些关键上下文已经存在于浏览器里的 Web 应用，例如 Gmail、Salesforce、LinkedIn、内部工具、仪表盘或管理控制台。[1]
这对编码智能体来说是一个重要步骤。Codex 已经能在代码、仓库、类似终端的工作流和预览环境里工作。Chrome 给它增加了另一个工作表面：已登录的 Web。
OpenAI 官方文档对使用边界说得比较谨慎。如果任务是本地开发服务器、基于文件的预览，或者不需要登录的公开页面，OpenAI 建议先使用 Codex 的 in-app browser。Chrome 更适合那些确实需要用户真实浏览器上下文的场景。[1]
这个区分是理解 Codex Chrome 的最好起点。它不是要取代所有集成，而是让 Codex 在工作被锁在真实浏览器会话里时，也能进入那个表面执行任务。
OpenAI 如何说明 Codex Chrome 的作用
官方页面把它称为 Codex Chrome extension。这个扩展把 Chrome 与 Codex app 连接起来，让 Codex 可以执行需要用户登录状态的浏览器任务。[1]
OpenAI 给出的例子包括：
- 打开 Salesforce，并根据通话笔记更新账户信息
- 使用 Gmail 或 LinkedIn 上下文
- 操作内部工具
- 处理没有专用集成的 Web 工作流[1]
这个产品也被放进了 OpenAI 更大的工具模型里。OpenAI 大致区分了三条路径：
| 任务需要什么 | OpenAI 建议的表面 |
|---|---|
| 稳定的专用集成 | plugin |
| 本地开发服务器、文件预览或公开页面 | Codex in-app browser |
| 已登录的网站或内部 Web 应用 | Chrome extension |
这个框架很重要，因为浏览器控制很强，但也很复杂。如果稳定的 plugin 或 API 存在，通常那会是更好的选择。浏览器控制真正有价值的地方，是工作流仍然停留在人类使用的 Web 界面里。
OpenAI 也把 Codex Chrome 建立在明确的权限控制之上。根据文档，Codex 在与一个新网站交互之前，会按 host 向用户确认。用户可以只在当前聊天中允许，也可以始终允许该 host，或者拒绝该网站。Computer Use 设置里也包含 domain allowlist 和 blocklist。[1]
风险表述也很直接。OpenAI 表示，页面内容应被视为不可信上下文。它还把 Always allow browser content 标记为 Elevated Risk，因为开启后 Codex 在使用网站前将不再询问。浏览器历史记录也被视为敏感信息，因为其中可能包含内部 URL、搜索词、telemetry 和活动记录。[1]
所以官方叙事有两面：
- Codex 需要 Chrome，是因为真实工作经常发生在已登录的 Web 应用里。
- Codex Chrome 需要护栏，是因为已登录的 Web 应用里包含敏感操作和敏感数据。
与 Claude for Chrome 相比有什么不同
Codex Chrome 与 Claude for Chrome 属于同一个大方向，但两个产品的出发点不同。
Claude for Chrome 是 Anthropic 把 Claude 放进用户浏览器工作流的一次尝试。Claude 可以在 Chrome side panel 中读取页面、点击、浏览网站、跨标签页工作，并帮助完成多步骤浏览器任务。[2][3]
Codex Chrome 的出发点不同。Codex 本来就是编码和工作智能体。Chrome 扩展让它在编码或运营工作流进入 Salesforce、Gmail、LinkedIn 或内部仪表盘等认证 Web 上下文时，继续完成任务。[1]
| 维度 | Claude for Chrome | Codex Chrome |
|---|---|---|
| 产品中心 | 通用 assistant 与 browser agent | 获得浏览器访问能力的 coding/work agent |
| 主要界面 | Chrome side panel | 与 Chrome 连接的 Codex app |
| 常见任务形态 | 读页面、点击、浏览、填表、辅助 Web 工作 | 在编码、运营、支持或业务工作流中使用已登录网站 |
| 上下文重点 | 当前页面、标签页、side-panel interaction | 已登录浏览器状态、host 权限、工具选择 |
| 强用例 | 通用浏览器工作和 Web 辅助 | 产品验证、内部工具、CRM/工单更新、认证工作流 |
| 主要风险 | prompt injection、可见敏感数据、宽泛浏览器自主性 | 登录会话、浏览器历史、内部网站、域名权限 |
可以这样简化理解：
- Claude for Chrome 把 assistant 带进浏览器。
- Codex Chrome 让 coding/work agent 在需要登录上下文时进入浏览器。
两者当然有重叠。它们都读取网页并在网页中行动。它们都需要权限系统。它们都绕不开 prompt injection 和敏感数据问题。但产品意图不同。Claude for Chrome 更像是能在 Web 应用里行动的 assistant。Codex Chrome 更像是一个 work agent，把浏览器当成多个执行表面之一。
浏览器控制正在成为通用智能体能力
这个模式并不只属于 OpenAI 和 Anthropic。
Hermes Agent、OpenClaw 这类智能体运行环境，也会把浏览器控制作为工具集的一部分。在这些环境里，浏览器不一定被包装成面向消费者的 Chrome 扩展。它更像是众多工具中的一个：打开页面、查看可见内容、点击、输入、滚动、截图、读取 console 输出，再与终端命令、文件修改、搜索、消息发送或调度结合。
这种包装方式的差异很重要。
Codex Chrome 和 Claude for Chrome 是产品化的浏览器集成。Hermes/OpenClaw 式系统则把浏览器控制作为更大智能体运行环境的一部分。方向是相似的：智能体需要以受控方式访问人类实际工作的表面。
这也是为什么浏览器控制会在多个产品里反复出现。浏览器仍然是现代工作的共同界面。即使后端有 API，人类的实际工作流也常常留在 Web 应用里。
为什么会出现这类程序
浏览器控制智能体出现，是因为早期 AI 辅助模式正在碰到边界。
聊天模型可以解释该怎么做。编码智能体可以修改仓库。plugin 可以调用一个窄 API。但很多真实任务位于这些类别之间。
一个支持工单可能需要读取 ticket、检查客户记录、打开仪表盘、比较日志、修改代码、验证 staging preview，然后更新工单。一个增长工作流可能需要检查 analytics、打开 CRM、起草邮件并记录结果。一个开发任务也可能需要修复 bug 后，在浏览器里证明 UI 真的正常工作。
这些工作流不是一次干净的 API 调用。它们本身就是浏览器形状的。
浏览器控制变得有吸引力，主要有五个原因。
1. 登录状态很重要
很多工具只有登录后才真正有用。Gmail、Salesforce、LinkedIn、管理仪表盘、账单门户、CMS、analytics 工具和内部 Web 应用，都依赖用户的账户状态。
模型可以知道 Salesforce 是什么。plugin 可以覆盖一部分 Salesforce 操作。但真实团队可能有 custom fields、custom dashboards、内部命名规则和审批工作流。这些上下文往往就在 Web 界面里。
2. API 和 plugin 覆盖不了一切
API 比浏览器自动化更干净。它更容易审计、更容易测试，在可重复工作流中通常也更安全。
但现实中的 API 并不完整。有些工具 API 很有限。有些内部工具没有公开集成。有些工作流变化太快，不值得专门做正式 connector。有些有用动作只暴露在 UI 里。
这时浏览器控制就成了 fallback execution layer。
3. 编码工作也需要产品验证
编码智能体能修改文件，并不等于产品真的能用。
对 Web 产品来说，最后的检查经常发生在浏览器里：登录、打开页面、点击流程、提交表单、检查仪表盘、查看 console、检查 network error，并把结果与任务要求对比。
这就是 Codex Chrome 与编码智能体天然契合的原因。修改代码的同一个智能体，也可能需要在浏览器里检查产品并确认改动行为正确。
4. 工作会跨越标签页和系统
人的工作很少被限制在一个应用里。
一个现实任务可能同时涉及 GitHub、Linear、Slack、Gmail、staging URL、文档页面、CRM 和内部管理工具。浏览器控制让智能体可以沿着这条序列前进，而不需要用户把每一段上下文都复制粘贴出来。
5. 浏览器就是人类已经在工作的地方
最实际的理由也最简单。人们已经在浏览器里工作。
如果智能体要承担更长的任务，就需要进入已经存在的工作流。浏览器是 SaaS、内部工具、仪表盘、文档、表单和管理面板的共同表面。
这会带来什么变化
第一个结果是，编码智能体会开始扩展成 workflow agent。
过去评价编码智能体，主要看它能不能修改正确的文件。这仍然重要，但已经不是完整故事。更强的智能体应该能理解任务、修改代码、在产品中验证结果、更新相关工具，并报告发生了什么。
这会扩大工作的单位。
以前的请求可能是：
修复这个组件。
接下来的请求可能变成：
修复这个问题，在 staging 页面验证，更新工单，然后告诉我改了什么。
浏览器控制也会让权限设计成为核心产品功能。胜出的产品不会只是点击最多页面的智能体，而是能让用户放心授予有限、可理解权限的智能体。
这意味着以下能力会变得重要：
- 按网站审批
- domain allowlist 和 blocklist
- 敏感步骤的动作确认
- 独立浏览器 profile 或 session
- 用 tab grouping 做任务隔离
- audit trail 和 action log
- 清晰处理 browser history 和 page content
对企业来说，这一点更重要。企业买家会关心 admin controls、logging、data handling 和 policy enforcement。一个炫目的浏览器 demo 不够，如果智能体可能走进错误的内部系统，或者被恶意页面内容误导，企业很难采用。
安全问题也会更难。浏览器智能体会读取不可信网页，并可能在已登录会话中行动。这会让 prompt injection 变成带有真实后果的问题。恶意页面不需要用传统方式“黑进”模型，它只需要诱导智能体滥用已经获得的权限。
所以浏览器智能体的未来不只是点击能力变强。核心是受控的权限。
智能体接下来会关注哪里
浏览器控制智能体的下一阶段，很可能集中在五个方向。
1. 权限和策略层
用户和组织需要决定哪些网站允许访问，哪些动作需要确认，哪些表面永远禁止。OpenAI 的 allowlist/blocklist 模型已经指向这个方向。[1]
2. 会话隔离
智能体不应该随意继承用户浏览器生活的全部内容。专用 agent profile、按任务隔离的 session、临时 cookies 和受控 history access 会变得更重要。
3. 验证循环
浏览器控制不只用于执行动作，也用于检查结果。
强的编码智能体应该能够打开产品、检查 UI、读取 console errors、截图、比较状态，并判断任务是否真的完成。
4. 工作流组合
浏览器会成为更大链条中的一步：repository、terminal、browser、ticket system、docs、CRM 和 messaging。价值来自整条链，而不是某一次点击。
5. 更窄的自主性
近期赢家未必是能自由浏览整个 Web 的智能体。更可能先落地的是能稳定处理较窄工作流的智能体：更新 CRM 记录、测试 checkout flow、验证 pull request preview、triage support ticket，或从内部仪表盘收集 evidence。
换句话说，实用自主性可能首先是有范围的自主性。
Reddit 和社区反应透露了什么
围绕 Codex Chrome 本身的直接社区讨论目前还有限。研究时，精确搜索 Codex Chrome 的 Reddit thread 并不容易浮现，而且收集环境也无法直接访问 Reddit。
但仍然有可参考的社区信号。围绕 OpenAI Operator 和浏览器智能体的相关讨论，已经显示出用户在意的压力点。
在 r/ChatGPTPro 的一个 thread 中，有人询问还有没有人在使用 OpenAI Operator，以及 hype 退去后它表现如何。评论里呈现出兴趣与疲惫混合的状态。有用户说自己试了几个 use case，但因为智能体没有充分理解任务，很快就放弃了。另一个用户说它速度慢、不稳定，也没有带来实际可感知的时间节省。还有评论认为这个方向有前景但尚未准备好，并表示短期内 deterministic、narrow-scope agent systems 可能比宽泛浏览器智能体更有用。[5]
隐私也出现在反应里。有用户说，使用 agent-controlled browser 会让他们不舒服，因为他们不想把个人信息交给那个环境。[5]
这些评论不应被当作对 Codex Chrome 的判决。更合适的读法是：它们反映了用户对浏览器智能体这一类产品的早期情绪。
信息已经足够清楚：
- 用户希望智能体能跨真实网站工作；
- 他们不会长期容忍缓慢和不稳定；
- 他们希望智能体节省时间，而不是增加监督工作；
- 他们对个人数据和登录会话很敏感；
- 短期内，狭窄且可靠的工作流可能胜过宽泛自主性。
Codex Chrome 最终也会被放在这套标准下评判。
更大的趋势
Codex Chrome 是从 answer engine 转向 working agent 的一部分。
浏览器正在成为 AI 系统的执行表面，因为工作本身就是浏览器形状的。Claude for Chrome 从 assistant 侧展示了这个趋势。Codex Chrome 从 coding/work agent 侧展示了这个趋势。Hermes/OpenClaw 式运行环境则说明，浏览器控制也正在成为通用智能体基础设施的一部分。
接下来的竞争不会停留在智能体能不能打开网页、点击按钮上。那很可能会变成基本能力。
更难的问题是：智能体能否在真实工作流中安全、选择性地、有用地使用浏览器。
这就是 Codex Chrome 值得关注的地方。它把编码智能体连接到用户已登录的工作表面，同时也暴露出浏览器智能体的核心张力：让它有用的访问权限，也正是让它变得危险的访问权限。
References
- OpenAI Developers, Codex Chrome extension – Codex app
https://developers.openai.com/codex/app/chrome-extension - Anthropic Support, Get started with Claude in Chrome
https://support.claude.com/en/articles/12012173-get-started-with-claude-in-chrome - Anthropic Support, Claude in Chrome Permissions Guide
https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide - OpenAI, Introducing Operator
https://openai.com/index/introducing-operator/ - Reddit, r/ChatGPTPro, Anyone still using OpenAI’s Operator feature? How’s it holding up now that the hype is gone?
https://reddit.com/r/ChatGPTPro/comments/1kcg1gj/anyone_still_using_openais_operator_feature_hows/ - The New Stack, OpenAI Codex arrives in the browser with new Chrome extension
https://thenewstack.io/openai-codex-chrome-extension/