Codex Chrome 插件：让 AI 使用你的浏览器登录态
Codex Chrome 插件是 Codex App 的浏览器能力扩展，适合处理必须依赖 Chrome 登录态、浏览器上下文或真实网页操作的任务。
当任务必须依赖你的 Chrome 登录态、浏览器上下文或真实网页操作时，让 Codex 在你授权的范围内进入这条工作流。
比如：
•
你要让 Codex 读取登录后才能看到的 CRM、邮箱、后台系统；
•
你要在真实业务页面里复现一个 bug；
•
你要让它根据页面状态回到代码仓库里修复问题；
•
你要上传一个本地文件到网页表单，再核对页面结果；
•
你要处理没有 API、只有网页操作入口的内部系统。
🤖
这些任务过去通常只能靠人手动完成，AI 最多在旁边给步骤建议。Chrome 插件补上的，就是“真实浏览器环境”这一段。
先说结论
Codex Chrome 插件不是普通网页摘要插件，也不是一个独立聊天机器人。它是 Codex App 的浏览器能力扩展。
我的使用判断很简单：
•
本地开发预览、公开网页、无需登录的页面，优先用 Codex 的 in-app browser；
•
某个系统有专门插件或结构化集成时，优先用对应插件；
•
只有任务必须依赖 Chrome 登录态、浏览器 profile、cookies 或真实网页操作时，再使用 Chrome 插件；
•
涉及付款、转账、删除生产数据、安全设置、导出敏感信息时，让 Codex 准备和核对，不要让它直接提交关键动作。
也就是说，它的价值不是“更方便地打开网页”，而是让 Codex 可以参与完整验证链路：看页面、操作后台、复现问题、回到代码里修复，再继续验证。
基础信息
#oikiWKpODJko text { white-space: pre; }#oikiWKpODJko .fb0 { stroke: var(--N900-FG, 0.15); }#oikiWKpODJko .fb0 {stroke: rgba(31,35,41, 0.15)}#oikiWKpODJko .fx0 { stroke-miterlimit: 10; }#oikiWKpODJko .fx0 {stroke-miterlimit: 10}#oikiWKpODJko .fa1 { fill: rgb(187, 191, 196); }#oikiWKpODJko .fa1 {fill: rgb(187, 191, 196)}#oikiWKpODJko .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#oikiWKpODJko .fx1 {font-style: normal}#oikiWKpODJko .fx2 { text-anchor: middle; }#oikiWKpODJko .fx2 {text-anchor: middle}#oikiWKpODJko .fx3 { dominant-baseline: central; }#oikiWKpODJko .fx3 {dominant-baseline: central}#oikiWKpODJko .fx4 { stroke: none; }#oikiWKpODJko .fx4 {stroke: none}#oikiWKpODJko .fc0 { fill: var(--text-caption); }#oikiWKpODJko .fc0 {fill: #646a73}#oikiWKpODJko .fa2 { fill: var(--text-link-disabled); }#oikiWKpODJko .fa2 {fill: rgb(187, 191, 196)}#oikiWKpODJko .fc1 { stroke: var(--B500); }#oikiWKpODJko .fc1 {stroke: #336df4}#oikiWKpODJko .fx5 { font: 400 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#oikiWKpODJko .fx5 {font-style: normal}#oikiWKpODJko .fx6 { text-anchor: start; }#oikiWKpODJko .fx6 {text-anchor: start}#oikiWKpODJko .fx7 { dominant-baseline: alphabetic; }#oikiWKpODJko .fx7 {dominant-baseline: alphabetic}#oikiWKpODJko .fc2 { fill: rgb(23, 23, 23); }#oikiWKpODJko .fc2 {fill: rgb(23, 23, 23)}#oikiWKpODJko .fc3 { fill: var(--B500); }#oikiWKpODJko .fc3 {fill: #336df4}#oikiWKpODJko .fb1 { fill: var(--N900-FG, 0.15); }#oikiWKpODJko .fb1 {fill: rgba(31,35,41, 0.15)}#oikiWKpODJko .fb2 { fill: rgb(209, 213, 219); }#oikiWKpODJko .fb2 {fill: rgb(209, 213, 219)}#oikiWKpODJko .fa3 { fill: var(--bg-body); }#oikiWKpODJko .fa3 {fill: #fff}AB123456789项目名称官方文档所属产品核心定位典型场景推荐搭配权限模型安全重点信息Codex Chrome extensionCodex App让 Codex 使用 Chrome 处理需要登录态的浏览器任务Gmail、Salesforce、LinkedIn、CRM、内部系统、需要账号登录的网页流程Codex App、Plugins、In-app Browser、Computer Use新站点默认请求确认；支持 allowlist / blocklist页面内容按不可信上下文处理，敏感操作需要人工确认https://developers.openai.com/codex/app/chrome-extension
它解决的真实边界
很多 AI 编程工具都能读代码、改文件、跑命令，但一进入真实网页环境，就会遇到新的边界：
•
页面需要登录；
•
数据只存在浏览器会话里；
•
内部系统没有稳定 API；
•
复现问题必须点击真实页面；
•
本地开发页面和线上后台之间要来回验证；
•
有些任务需要复制、上传、下载、截图或核对页面状态。
没有 Chrome 插件时，Codex 可以告诉你“下一步点哪里”，但它自己无法在你的登录态页面里继续推进。接入 Chrome 后，它可以在你确认的网站里完成更长的任务链路。
一个典型流程可能是这样：
代码块
Plain Text
@Chrome 打开后台的订单详情页，核对这个用户的订阅状态。
如果页面显示异常，回到仓库里检查对应接口和前端展示逻辑。
修复后再用浏览器验证页面是否恢复正常。
这类任务的重点不是浏览器自动化本身，而是 Codex 能把“网页证据”和“代码修改”放进同一个工作线程里。
和 in-app browser 怎么分工
官方文档里把边界说得很清楚：本地开发服务器、文件预览、公开页面、无需登录的页面，优先用 in-app browser。这样可以把预览和验证留在 Codex 内部，不必动用你的 Chrome profile。
Chrome 插件更适合这些场景：
•
页面必须依赖你的 Chrome 登录态；
•
任务需要访问真实账号下的数据；
•
需要浏览器 profile、cookies 或扩展环境；
•
本地预览工具无法完成登录、权限或业务状态验证；
•
目标系统没有可用 API，只能通过网页操作。
我的建议是：能不用真实登录态，就不用真实登录态；必须用时，再把权限收窄到当前任务。
核心能力
连接 Chrome，使用真实登录态
安装和连接完成后，Chrome 工具栏里的 Codex 扩展会显示 Connected。之后你可以在新的 Codex 线程里直接指定 Chrome 任务，例如：
代码块
Plain Text
@Chrome open Salesforce and update the account from these call notes.
这里真正重要的是：Codex 使用的是你的 Chrome 环境，而不是一个无登录态的临时浏览器。因此它可以处理 Gmail、Salesforce、LinkedIn、CRM、内部后台这类必须登录后才能访问的页面。
新网站默认需要确认
Codex Chrome 插件默认不会无差别使用所有网站。它在访问每个新网站前会询问，通常按 host 维度确认，例如 example.com。
你可以根据任务风险选择：
•
只允许当前聊天使用这个网站；
•
将该 host 加入长期允许列表；
•
拒绝访问这个网站。
这个设计很关键。因为登录态浏览器里可能有邮箱、后台、财务系统、内部工具和个人账号，不能把“能访问”直接等同于“应该访问”。
支持 allowlist / blocklist
官方文档提到，可以在 Computer Use 设置里管理域名 allowlist 和 blocklist：
•
allowlist：Codex 可以再次使用这些域名，不需要每次重复确认；
•
blocklist：Codex 不应该使用这些域名；
•
从 allowlist 移除后，下次会重新询问；
•
从 blocklist 移除后，Codex 可以重新发起请求，而不是继续视为禁止。
高频、低风险、任务边界清楚的网站，可以考虑放进 allowlist。邮箱、金融、账号安全、生产后台这类页面，我更倾向于临时授权或保持人工确认。
文件上传需要额外开启 file URL 权限
如果 Chrome 任务需要上传本机文件，官方文档要求在 Chrome 扩展详情里开启 Allow access to file URLs。
路径大致是：
代码块
Plain Text
Chrome toolbar → Extensions → Manage Extensions → Codex → Details → Allow access to file URLs
这类权限建议按需开启。因为一旦涉及本地文件，任务边界就从“网页操作”扩展到了“本机文件 + 网页上传”。明确需要上传时再开，用完后重新评估是否保留。
使用时最应该注意什么
把网页内容当成不可信上下文
官方文档明确提醒：页面内容应该被视为 untrusted context。
原因很直接：网页里可能包含误导性文本、隐藏指令或恶意内容。如果 Codex 把网页内容当成用户指令，就可能发生越权操作或数据外发。
所以使用 Chrome 插件时，我建议保持几个习惯：
•
不要让 Codex 访问和任务无关的敏感页面；
•
首次访问某个站点时认真看确认弹窗；
•
对邮箱、财务、账号、安全设置类页面保持人工复核；
•
不要把密码、密钥、恢复码等敏感信息交给浏览器任务；
•
复杂任务拆小，每一步都能看清楚结果。
谨慎开启 Always allow browser content
官方把 “Always allow browser content” 标成 Elevated Risk。开启后，Codex 使用网站时不再每次确认。
这对高频低风险站点可能方便，但对真实账号环境来说风险会明显上升。我的建议是：默认不要全局开启。除非你非常确定站点不敏感、任务边界稳定，并且你能接受它被长期授权。
浏览器历史不是普通上下文
浏览器历史可能包含内部 URL、搜索词、业务系统路径、账号活动记录等信息。官方文档也说明，Codex 在需要浏览器历史时会单独询问，而且浏览器历史没有 always-allow 选项。
这个设计是合理的。历史记录不是普通辅助信息，它可能暴露你的工作习惯、内部系统结构甚至业务线索。除非任务确实需要，否则不建议授权。
适合哪些任务
Codex Chrome 插件比较适合：
•
在 CRM / 后台系统里按说明更新资料；
•
读取登录后才能访问的业务页面，并结合代码修改；
•
在真实网页里复现 bug；
•
验证需要账号态的功能流程；
•
处理内部工具、低代码后台、工单系统这类没有稳定 API 的任务；
•
根据页面结果回到代码仓库里继续修复问题；
•
上传文件、核对页面状态、下载结果并继续处理。
不太适合一上来就交给它的动作包括：付款、转账、删除生产数据、修改安全设置、导出大量个人信息。即使工具能做，也应该把这些动作留给人工确认。
快速上手
按照官方文档，基本流程是：
代码块
Plain Text
如果连接异常，可以先检查：
•
Chrome 扩展是否显示 Connected；
•
Codex App 里的 Chrome plugin 是否开启；
•
当前是否使用安装了扩展的 Chrome profile；
•
目标网站是否在 blocklist；
•
是否需要重启 Chrome / Codex；
•
上传本地文件时，是否开启了 Allow access to file URLs。
我的使用建议
如果你把 Codex 当成工程协作者，而不是单纯聊天机器人，Chrome 插件会很有用。它让 Codex 不只停留在代码仓库里，还能进入真实页面完成验证闭环。
但越接近真实账号和真实业务系统，越要收紧权限。
我会按这个顺序使用：
公开页面、本地页面：先用 in-app browser；
结构化系统：优先用专门插件或 API；
必须登录态：再用 Chrome 插件；
高风险动作：只让 Codex 准备、检查、解释，由人最终确认。
这样用，Chrome 插件不是“把浏览器交给 AI”，而是把一段过去必须人工完成的验证流程，变成可控、可复核、能回到代码里的协作流程。