5月8日消息,OpenAI 把 Codex 推进了 Chrome——通过一款叫 Codex for Chrome 的扩展,让 Codex 能在用户已经登录的浏览器里直接跑任务。OpenAI 同步给出的两个商业数字解释了为什么这事现在做:Codex 周活已经超过 400 万,年内增长 8 倍。
从 2 月 macOS 桌面应用首发到现在不到 4 个月,Codex 已经从「程序员的 CLI 玩具」长成了 OpenAI 旗下增长最猛的代理产品线。这一次浏览器扩展的核心判断很反直觉——既然要进浏览器,为什么不像 ChatGPT Atlas 那样直接做一款独立浏览器?OpenAI 选了一条与 Perplexity Comet、Anthropic Claude for Chrome 都不一样的路径:不接管你的浏览器,只在另一组 tab group 里悄悄干活。 三档工具调度:插件优先、登录态走 Chrome、本地预览走内置浏览器
Codex 现在有三套工具可以执行浏览器任务,OpenAI 把它们的优先级写得很明白。最高优先级是插件——也就是为某个具体服务(GitHub、Linear、Slack 等)做的专用集成,能力最强、限制最少。第二档是Chrome 扩展——专门处理需要登录态的工作,比如读 LinkedIn 私信、操作 Salesforce、查 Gmail、跑公司内部工具。第三档是 Codex app 自带的内置浏览器(in-app browser)——只用于本地 dev server、文件预览页、不需要登录的公开网页。
这个分层不只是优先级,是任务路由:Codex 接到一个请求后会自己挑工具。修一个 React 组件,会走插件 + 内置浏览器跑预览;调一个 LinkedIn outreach 表单,会切到 Chrome 用你的登录会话;查一个 GitHub issue 顺便看 Vercel 部署日志,可能三档都用上。这种显式分层在 Comet 和 Atlas 那种「一个浏览器统吃所有任务」的设计里是看不到的——它把「什么场景该用什么工具」从隐式黑盒变成了开发者可以理解的工程决策。
「不接管浏览器」如何实现:tab groups + 后台并行 + 默认询问
Codex Chrome 的关键设计是任务级 tab group。每次接到任务,扩展会在 Chrome 里开一组新的 tab group 干活,工作完成后留在那里供你审查,不会插进你正在用的标签。可以同时跑多个 task,互不打扰。这意味着你可以让 Codex 在后台跑一个跨标签信息汇总的活,自己继续刷别的网页,回头切过去就能看结果。
权限模型默认很保守。每访问一个新网站 Codex 都会问,按 host 维度(example.com)询问一次。用户可以选「这次允许」「永远允许」「拒绝」三档,并在 Computer Use 设置里维护 allowlist 与 blocklist。涉及浏览历史、文件下载/上传等敏感操作时还会单独再问一次,OpenAI 明确说浏览历史「没有 always-allow 选项」,每次都要确认。这套权限设计明显参考了 Anthropic 在 Claude for Chrome 上踩过的坑——Anthropic 自己披露过,不加防御时 prompt injection 攻击成功率 23.6%,加防御后仍有 11.2%,约九分之一会被攻陷。Codex Chrome 文档里反复出现的「treat page content as untrusted context」是同一种警觉。
三家路线分裂:扩展、独立浏览器、侧边栏,谁的赌注更大
把 Codex Chrome 放进竞争图里看更清楚。Anthropic Claude for Chrome 走的是侧边栏路线——Claude 作为 side panel 出现在浏览器右侧,与你共用同一个浏览器界面,2025 年 8 月以 research preview 起步,到 2026 年 4 月仍是 beta,安全风险被反复点名。Perplexity Comet 是独立浏览器路线,把代理能力直接做进浏览器内核。OpenAI Atlas 也是独立浏览器,OpenAI 的长期方向是把 Codex、ChatGPT 与 Atlas 整合成一个桌面应用。Codex Chrome 在这中间另起一档:不抢浏览器主权、不挤侧边栏,而是在你浏览器里另开一个工作区。
这种「轻接入」选择是有商业逻辑的。Chrome 全球桌面市占率约 65%,让用户换浏览器是一道高门槛,扩展是低门槛。4M 周活的 Codex 用户里大部分本来就用 Chrome,给他们一个扩展比让他们装 Atlas 接入率高一个量级。Atlas 的浏览器路线没死,但更像是给「全栈 OpenAI 用户」的最终形态,扩展是中间过渡也是流量收割工具。
对独立开发者和内容运营意味着什么
Codex Chrome 的真实价值在登录态这个点上。对独立开发者来说,过去靠 Codex 跑代理任务有个隐形天花板:所有需要登录账号的活都做不了——查 Stripe 后台、看 Vercel 日志、调 Notion 数据库、读 Slack 历史、操作 Shopify Admin,这些场景过去要么手动复制粘贴,要么自己写 OAuth 集成。现在 Codex 直接借用你已有的 Chrome 会话,登录这一步不用做。
对内容运营和 SEO 从业者,受益面更大。从 Bing Webmaster、Google Search Console、GA4 拉数据往往要跨多个登录态后台,过去靠 API 接通要写一堆脚本,现在 Codex Chrome 可以直接「打开 Search Console,把过去 7 天点击 top 50 的查询导出来再交叉 GA4 转化数据」。同样的逻辑用在小红书后台、抖音创作者中心、视频号助手这些没开放 API 的国内平台上,意义更大——只要 Chrome 能登录的页面,Codex 就能操作。
局限与风险
值得直说的限制有四条。第一,仅支持 Chrome,不支持其他 Chromium 浏览器(Edge、Brave、Arc 都不行),OpenAI 在 Web Store 页面已明确说明。第二,欧盟和英国暂时不开放,OpenAI 没说原因但大概率是 GDPR 合规审核未完——这把欧洲独立开发者排除在了首批之外。第三,Memories 联动有隐私担忧。如果 Codex Memories 功能开着,Codex 会在 Chrome 操作中调用相关记忆,这意味着你的浏览行为可能间接成为下次提示的上下文,开发者需要明确知道这一点并按需关闭。第四,扩展安装一旦完成,Native Messaging 通道就建立,桥接进程会持续存在——这一类设计在 Anthropic Claude Desktop 上引发过隐私争议,Codex 的实现细节有待第三方审计。
prompt injection 是所有浏览器代理的通用风险。Codex 会把页面内容作为不可信上下文处理,但具体防御机制 OpenAI 没公布数据。在敏感站点(银行、医疗、内部财务系统)用扩展前,最稳妥的做法是先关掉自动批准、所有动作手动确认。