夜雨聆风Codex 的 chrome 插件和 browser 插件，核心代码逐字节相同
约 1789 字·阅读 5 分钟
做了一次文件比对——browser 插件和 chrome 插件目录下各有一个 browser-client.mjs，都是 3252 行，逐字节相同。
同一份代码，两个插件共用。
但定位完全不同。browser 操作的是 ChatGPT 自带的内置浏览器，一个隔离的沙箱。chrome 操作的是你电脑上真实运行的 Chrome——你已登录的账号、你打开的标签页、你装的扩展，AI 全都能用。
同一份核心，接上不同的"接入层"，就变成了两个风险等级完全不同的产品。
· · ·
01
为什么操作真实 Chrome 这么难
要让外部程序控制 Chrome，不是调个 API 就行。Chrome 出于安全考虑，不允许任意进程直接操控用户的浏览器。
所以 chrome 插件用了 Google 官方提供的标准桥接机制——_Native Messaging_（原生消息）。
整条链路是这样走的：AI 调用 browser-client.mjs 暴露的 JS API（这和 browser 插件一模一样），然后 browser-client.mjs 通过本地 socket 连到一个叫 extension-host.exe 的独立程序。这个程序把 socket 消息翻译成 Chrome 能理解的"原生消息"格式，通过标准输入输出传给 ChatGPT for Chrome 浏览器扩展。扩展有权限调用 Chrome 的 chrome.tabs、chrome.debugger 等 API，最终操作你真实的 Chrome。
四层各自负责一件事：JS API 给 AI 干净的接口，extension-host 做协议翻译，扩展执行操作，Chrome 是最终目标。
关键决策在这里：当目标系统有严格的安全边界时，不要尝试绕过它，而是用官方提供的扩展点搭一座合规的桥。Chrome 不让你随便操控？那就走它官方支持的 Native Messaging 通道。
· · ·
02
原生消息清单：让 Chrome 信任这个 Host
chrome 插件比 browser 多了一整套"安装、检查、启动"的脚本，全是围绕原生消息 Host 服务的。这是整个插件最硬核的部分。
Chrome 规定：只有写在特定路径下的 JSON 清单里登记过的 Host，才被允许被扩展调用。这份清单的位置因系统而异——macOS 和 Linux 是写文件到固定目录，Windows 不一样，还得写注册表。
在 Windows 上，Chrome 不直接扫文件夹，而是去注册表里找 HKCU\Software\Google\Chrome\NativeMessagingHosts\<host-name> 的默认值，那个值才是清单文件的路径。所以 installManifest.mjs 在 Windows 上除了写 JSON 文件，还要调 reg add 命令把路径塞进注册表。
清单内容本身不长，四个关键字段：Host 的唯一标识 name，可执行文件绝对路径 path，通信方式 type: "stdio"，以及 allowed_origins——只有指定的扩展 ID 才被允许调用这个 Host。这是防滥用的关键，不是谁都能连。
chrome 插件还有一堆"自检"脚本：check-extension-installed.js 检查扩展装了没，check-native-host-manifest.js 检查清单对不对，chrome-is-running.js 检查 Chrome 在不在跑。如果检查失败，AI 会去读 docs/chrome-troubleshooting.md，按步骤修复，而不是瞎试。
· · ·
03
安全设计：比 browser 更敏感
chrome 插件操作的是用户真实的浏览器、真实的登录态，安全要求比 browser 更严。
从 plugin.json 的描述就能看出 OpenAI 的谨慎："Browser content may include sensitive information from logged-in sites."（浏览器内容可能包含已登录站点的敏感信息。）
核心安全原则和 browser 一脉相承——页面内容不可信，读不等于写，敏感数据传输前要确认。但 chrome 多了一条特别的规定，写在 unified-skill.md 里：
Do not inspect browser cookies, local storage, profiles, passwords, or session stores. Browser discovery must remain read-only.
不要去翻 Cookie、localStorage、用户档案、密码、session 存储。浏览器发现过程必须是只读的。
这条很关键。AI 连上你的真实 Chrome 后，理论上它能看到你所有的登录态。但 skill 文档明确划了红线——碰都不能碰。
有个有意思的细节：plugin.json 里 capabilities 字段，chrome 插件只有 ["Interactive", "Read"]，比 browser 少了一个 "Write"。虽然实际运行时 AI 确实能输入文字、提交表单，但插件层面的能力声明故意保守。元数据声明和实际能力之间，要有清晰的边界约定——粗粒度标签给权限管理用，细粒度控制交给运行时确认机制。
· · ·
04
为什么共享同一份核心代码
两个插件的核心运行时代码完全一样，差异只在怎么连接到浏览器（内置浏览器走应用内部通道，Chrome 走 Native Messaging）、配套脚本（Chrome 多了一堆安装检查工具）和使用场景。
这种"同一份核心 + 不同接入层"的设计好处很明显。bug 修一处，两个插件都好。AI 学一套 API 就能同时操控两种浏览器。以后要支持 Firefox、Edge，只需要新写一个接入层，核心不动。
_接入层和核心层物理分离_，是可扩展架构的关键。browser 插件证明了这套核心可以接沙箱浏览器，chrome 插件证明了它可以接真实浏览器，computer-use 插件后面会证明同一套思路还能接整台桌面。
· · ·
05
为什么这篇文章值得你转发
chrome 插件的核心贡献不在功能——操作真实 Chrome 这件事，Selenium 和 Puppeteer 早就能做。它的贡献在于示范了"怎么合规地操作一个有安全边界的系统"：用官方扩展机制，不绕过；跨平台分别处理注册机制；前置自检加故障排查文档；能力越大，约束越细。
如果你在做企业自动化或者需要操作用户已登录的 SaaS 工具，这个插件的 Native Messaging 桥接是一份现成的参考实现。你的 agent 项目里，是怎么处理跨平台兼容和安全边界的？ 评论区聊聊。顺手转发给也在搞 agent 的朋友。
· · ·
「拆解 Codex 7 大插件」系列 · 第 3 篇 · 共 9 篇下一篇：让 AI 操作整台 Windows，OpenAI 只掏出了三个系统 API。
感谢关注