Codex 钻进浏览器了：400 万周活用户、8 倍增长，OpenAI 在布什么局？
2026 年 5 月 7 日，OpenAI 扔出了一个看似低调、实则重要的更新——Codex Chrome 扩展正式上线，macOS 和 Windows 双平台支持。
不是新模型，不是新框架，就是一个浏览器扩展。但这个东西的背后逻辑，比表面看起来深得多。
一个数据先摆出来
Codex 现在的周活跃用户已经超过 400 万，是今年年初的 8 倍。
8 倍。不是 80%，不是 2 倍，是 8 倍。
这个增速说明一件事：AI 编程工具不是在稳步增长，是在爆炸。而 OpenAI 在这个节点推出 Chrome 扩展，不是锦上添花，是在给火箭加燃料。
它到底能干什么
先搞清楚这个扩展不是做什么的——它不是又一个「AI 帮你浏览网页」的工具。它和 Computer Use 不一样，Computer Use 是接管你的屏幕，直接操控鼠标键盘。Chrome 扩展走的是另一条路：在后台并行工作，不抢你的浏览器。
具体来说：
- 用你的登录态操作网站。LinkedIn、Salesforce、Gmail、公司内部系统——这些需要登录才能访问的页面，以前 API 搞不定，插件覆盖不到。现在 Codex 直接用你的 Chrome 登录态进去干活。
- 跨标签页并行获取上下文。比如同时打开 5 个竞品页面，Codex 在一个独立的标签组里并行读取、对比、总结。你的主标签页该干嘛干嘛。
- 直接调用 Chrome DevTools。对开发者来说，这意味着 Codex 可以直接检查网络请求、查看控制台日志、分析页面性能——不是模拟，是真的在用 DevTools。
- 操作本地文件。需要上传文件到网页？Codex 能直接从你的电脑里选文件传上去。
一句话总结：以前只能「看」网页的 AI，现在能「用」网页了。
三层工具体系
这个扩展不是孤立的。OpenAI 给 Codex 设计了一个三层工具架构：
- 专用插件层——GitHub、Slack、Figma、Notion 这些有现成 API 的服务，直接用插件搞定，效率最高
- Chrome 扩展层——需要登录态、需要真实浏览器环境的任务，走这条路
- 内置浏览器层——本地开发服务器、公开页面、文件预览，用沙箱化的内置浏览器，安全隔离
Codex 会自动选择用哪一层，你也可以手动指定——在对话框里打 @Chrome 就行。
这个三层设计的聪明之处在于：不把所有场景塞进一个方案。需要安全隔离的用内置浏览器，需要真实登录态的走 Chrome，有专用集成的走插件。每层各司其职，互不干扰。
权限模型：逐站确认，不是全开
把浏览器权限交给 AI，安全问题肯定是第一反应。OpenAI 的做法是逐站授权：
- 默认情况下，Codex 每访问一个新网站都会弹窗问你。三个选项：本次对话允许、始终允许、拒绝
- 可以管理一个允许列表和屏蔽列表，精确到域名级别
- 浏览器历史记录访问没有「始终允许」选项——每次都要手动确认，而且只限当次请求
关于数据存储：OpenAI 不会单独存储你的浏览器操作记录。只有当浏览器活动进入 Codex 的对话上下文时（比如读取的页面文字、截图、工具调用记录），才会被存储。ChatGPT 和 Codex 的数据控制策略同样适用。
但有一个需要警惕的风险：提示词注入。恶意网页可以嵌入专门设计来操控 AI 行为的指令。OpenAI 的建议是：在允许 Codex 访问之前，先审查网站内容。
为什么这件事值得关注
作为一个做产品的人，我看这件事有几个角度：
第一，浏览器正在变成 AI Agent 的主战场。
OpenAI 自己说得很直白：推出 Computer Use 之后，发现用户最常见的 workflow 都在浏览器里。这不是猜测，是数据说话。Codex 400 万周活用户，大多数工作流绕不开浏览器。与其让 AI 在桌面应用里隔靴搔痒，不如直接钻进浏览器。
第二，登录态是 AI Agent 的「最后一公里」。
API 能做的事有限。大量的企业内部工具、SaaS 后台、管理面板，根本没有开放 API。就算有，权限审批流程能把人耗死。Chrome 扩展绕过了这堵墙——它不调用 API，它直接操作网页。这对于一人公司、小型团队的自动化场景来说，是降维打击。
第三，「不抢浏览器」是一个产品设计的分水岭。
Computer Use 接管屏幕，你看着它动。Chrome 扩展在后台跑，你继续干你的。这两个模式的差异不是技术上的，是产品哲学上的：AI 到底是替你做事的工具，还是一个需要你盯着的实习生？
Chrome 扩展模式更接近前者。
第四，配合三层架构，Codex 在做一件事：让 AI Agent 自己选工具。
你不用纠结「这个任务用插件还是浏览器」，Codex 自己判断。这听起来像个小功能，但本质上是 Agent 自主决策能力的一个切面。未来 AI Agent 的核心竞争力不是「能做什么」，而是「知道什么时候该用什么做」。
局限和风险
说实话，不是所有东西都完美。
Chrome 扩展目前只支持 Chrome。Brave、Edge、Arc 这些 Chromium 内核的浏览器统统不支持。对习惯用 Arc 或 Brave 的用户来说，还得专门为 Codex 开着 Chrome。
权限范围也够广的——扩展申请了「读取和修改所有网站数据」「读取和修改浏览历史」「管理下载」「管理标签组」等一堆权限。虽然 OpenAI 加了自己的确认层，但 Chrome 层面的权限一旦授予，扩展本身的能力边界是很大的。
另外，欧盟和英国目前不可用。合规问题，没什么好说的。
和 Computer Use 怎么选
简单说：
| 场景 | 用什么 |
|---|---|
| 本地开发、预览、公开页面 | 内置浏览器 |
| 需要登录态的 SaaS/内部工具 | Chrome 扩展 |
| 桌面应用操作、跨应用工作流 | Computer Use |
| GitHub/Slack/Figma 等有专用集成的 | 插件 |
不是替代关系，是互补关系。一个 agent，四种触达方式。
接下来会怎样
从公开信息来看，OpenAI 的路线图里还有几个大招：
- Voice Mode 可能在 Google I/O（5 月 19-20 日）前后进入 Codex，用的刚发布的 GPT-Realtime-2 模型
- Remote Control 功能在测试中，可以通过 SSH 远程操控机器，甚至手机控制桌面
- 最终目标是一个合并的 App，把 Codex、ChatGPT 和 Atlas 浏览器统一到一个入口
回到现在这个时间点——Codex Chrome 扩展看起来只是一个小更新。但它背后的趋势很清楚：AI Agent 在从代码编辑器里走出来，进入你真正干活的每一个地方。
浏览器是第一步。下一步可能是你的整个操作系统。
发布日期：2026-05-13信息来源：OpenAI Developers、MacRumors、The Verge、Thurrott、Technobezz、MarkTechPost