夜雨聆风OpenAI 发布 Codex Chrome 扩展，让 AI agent 直接进入用户的 Chrome 浏览器——登录态的 Gmail、Salesforce、LinkedIn、企业后台，全都能操作。更炸裂的是，它能在后台同时跑多个标签页任务，而你完全感知不到。MacRumors 引述 OpenAI 数据：Codex 周活跃用户已突破 400 万，较年初暴涨 8 倍。但随之而来的权限清单，也足以让安全意识强的人倒吸一口凉气。
一句官宣，Codex 的工作边界直接推到浏览器
5 月 7 日，OpenAI 官方发推：
"Codex now works directly in Chrome on macOS and Windows. It's even better at working with apps and sites in Chrome, and now works in parallel across tabs in the background without taking over your browser."
「Codex 现在直接在 macOS 和 Windows 的 Chrome 里工作。它在 Chrome 中处理应用和网站的能力更强了，能在后台跨标签页并行工作，同时不会接管你的浏览器。」
▲ OpenAI 官方推文，抓取时已获得超 1.1 万点赞、173 万次浏览
这意味着什么？
过去 Codex 能写代码、能跑终端、能预览本地页面。但凡是需要你登录的网页——公司 CRM、内部管理后台、你的邮箱——它够不着。
现在这层墙被拆了。
后台并行、不抢焦点：这才是真正的产品差异
很多 browser agent 方案的痛点在于：agent 一启动就占住整个浏览器，你只能干看着它一个个标签页点。
OpenAI 反复强调的卖点是后台运行。Codex 会在任务专属的标签组（task-specific tab groups）里工作，收集信息、执行操作，但不会抢走你正在用的浏览会话。
一位用户 @damoosmann 评价：以前多个 session 容易把浏览器占住，现在用户可以继续工作，agent 在后面默默跑。另一位 @Nafees_Ai 的概括更直觉——以前你自己开 20 个 Chrome 标签页来回切，现在一个 AI agent 替你同时用 20 个标签页。
已经有开发者试过了。@plainscope 表示用了几小时后，直接与 Chrome 元素交互明显加速了前端迭代流程。
登录态才是关键：Gmail、Salesforce、LinkedIn 全能进
OpenAI 的官方文档把使用场景写得很明确：
"The Codex Chrome extension lets Codex use Chrome for browser tasks that need your signed-in browser state. Use it when Codex needs to read or act on a site such as LinkedIn, Salesforce, Gmail, or internal tools."
「Codex Chrome 扩展让 Codex 使用 Chrome 来处理需要你已登录浏览器状态的任务。当 Codex 需要读取或操作 LinkedIn、Salesforce、Gmail 或内部工具等网站时，就用它。」
▲ OpenAI Developers 文档详细说明了 Chrome 扩展的使用场景与权限边界
这里的重点在于登录态。公开网页、本地开发服务器、文件预览这些，OpenAI 建议继续用 Codex 内置浏览器。Chrome 扩展专门针对那些你已经登录的应用和网站。
换句话说，OpenAI 看中的是企业用户每天花大量时间操作的那些后台系统——Codex 要替你在这些系统里干活。
底层怎么干的？写代码、选工具、自己组合
OpenAI 的 thread 里还透露了一些底层逻辑：
"Under the hood, it writes and runs code to navigate and complete tasks."
「底层实际上是写代码并运行，来导航和完成任务。」
"If a task needs multiple tools, Codex chooses the best one for each step. It uses plugins when they can handle the job, Chrome when it needs a logged-in website, and combines approaches as needed."
「如果一个任务需要多种工具，Codex 会为每一步选择最合适的——插件能搞定的就用插件，需要登录网站的就用 Chrome，必要时会组合使用。」
也就是说 Codex 现在有三条工具线：
- 专用插件
：对接特定服务时用 - Chrome 扩展
：需要登录态网页时用 - 内置浏览器
：本地开发、公开页面时用
三条线按任务需要自动切换和组合。
权限清单长到吓人：读改所有网站、浏览历史、调试器全要
能力强，权限自然也重。
根据 OpenAI 官方文档，安装 Chrome 扩展时可能弹出的权限请求包括：
- Access the page debugger
（访问页面调试器） - Read and change all your data on all websites
（读取并修改所有网站上的所有数据） - Read and change your browsing history on all your signed-in devices
（读取并修改所有已登录设备上的浏览历史） - Display notifications
（显示通知） - Read and change bookmarks
（读取并修改书签） - Manage downloads
（管理下载） - Communicate with native applications
（与本地应用通信） - View and manage tab groups
（查看和管理标签组）
这份权限清单覆盖面非常广。
OpenAI 文档自己也把always allow browser content和browser history标注为Elevated Risk（高风险）。浏览历史可能包含内部 URL、搜索记录、已登录设备的 Chrome 会话活动等敏感信息。
▲ Chrome Web Store 上的 Codex 扩展，抓取时显示 11 位用户——页面刚上线不久
OpenAI 给了多层安全阀，但最终看用户怎么配
OpenAI 也明白权限这么重不能直接放开，所以给了几层控制：
网站访问控制：默认情况下，Codex 每访问一个新网站之前都会弹窗询问。用户可以选择：只允许本次聊天使用、始终允许该网站、或者拒绝。
敏感操作确认：Chrome Web Store 页面写得明确——"Codex always asks before sensitive actions."（Codex 在敏感操作前总会询问。）
黑白名单：Computer Use 设置里可以管理 allowlist 和 blocklist。
数据存储边界：OpenAI 声明不会从扩展单独存储完整的 Chrome 操作记录。只有被 Codex 读入上下文的内容——页面文本、截图、工具调用、摘要、消息——才会按 ChatGPT/Codex 的数据控制政策处理。
"Treat page content as untrusted context, and review the website before allowing Codex to continue."
「应当把网页内容视为不可信上下文，在允许 Codex 继续前先审阅网站。」
这段话出自 OpenAI 自己的文档，等于官方提醒：别无脑信任每个网页。
400 万周活用户、8 倍增长——OpenAI 为什么要把 Codex 推进浏览器
MacRumors 在报道中引述 OpenAI 的数据：Codex 的周活跃用户已经超过 400 万，较年初增长了 8 倍。
▲ MacRumors 报道称 Codex 周活超 400 万，较年初 8 倍增长
这个数字说明 Codex 已经从小众开发者工具变成了 OpenAI 重要的工作流产品。而浏览器是大量工作流的最后一公里——CRM 在浏览器里、后台管理系统在浏览器里、dashboard 在浏览器里、调试前端也在浏览器里。
把 Codex 接入 Chrome，本质上是把 agent 的工作面从"会写代码"推进到"能在你已有的网页环境里执行真实业务"。
▲ OpenAI Developers changelog 正式收录 "Codex for Chrome" 条目，时间标注 2026-05-07
社区已经在问下一层问题了
Chrome Web Store 页面写明："Codex does not support other Chromium-based web browsers at the moment."（Codex 目前不支持其他基于 Chromium 的浏览器。）
用户 @TheBootLoop 反馈在 Edge 里装了扩展，但 Codex 桌面端显示 Not connected，想知道是否会支持所有 Chromium 浏览器。还有 @Ixel111 和 @phpld 提到 Windows 或 UK/EU 地区在 app 中还没看到 Chrome 插件选项。
更深层的问题来自 @MindTheGapMTG：多个 agent 需要同时在 Chrome 里跑不同工作流时，标签页级别的隔离和每个 agent 各自的权限划分怎么做？单个 agent 用 Chrome 是体验升级，一旦多个 agent 并发共用同一个浏览器 profile，隔离和授权的复杂度会迅速上升。
还有 @ZilchfpBrandon 直接问技术细节：扩展底层是否用了 CDP（Chrome DevTools Protocol）？没有用户批准时怎么拿到权限？官方文档列出了"Access the page debugger"等 Chrome 权限项，但没有直接说明底层实现方案。
最后看回这件事
OpenAI 这次做的事情说起来只有一步：给 Codex 装了个 Chrome 扩展。
但这一步的含义是，AI agent 的工作面从代码仓库、终端、IDE，推进到了用户每天花最多时间的地方——浏览器里那些需要登录才能操作的系统。
能力很强，权限也很重。OpenAI 给了多层确认和控制机制，但最终效果取决于用户和企业管理员怎么配置。尤其是 always allow browser content 一旦开启，Codex 能读到的东西会远超你的预期。
浏览器 agent 这条赛道，OpenAI 已经下场了。
— END —
