Codex Chrome 扩展：安装配置、权限与修复方法

Codex Chrome 扩展并不是一个以 Codex 名义单独发布的扩展程序。OpenAI 目前的安装方式是：从桌面应用安装 ChatGPT 浏览器扩展，然后让 ChatGPT Work 或 Codex 任务通过 @ 提及选中这个已连接的浏览器。扩展程序只在你安装它的那个浏览器配置文件中生效，包括你明确允许的标签页和站点。

先说结论：这三条路径在 Agent 灵活性、登录态和窗口归属上各有取舍。内置浏览器从它自己的浏览器配置文件（Profile）启动，而不是你正在使用的那个窗口；扩展程序则以你的登录身份操作，但只能在你授权的浏览器配置文件和标签页内活动。如果你不希望 Agent 必须通过一座需要安装、逐站点授权、还得保持连接的桥才能访问页面，那么 ego (lite) 正是补上这一缺口的地方。

本指南先讲与搜索意图对应的扩展安装配置，再把它与内置浏览器、MCP 路径区分开。内置浏览器使用自己的配置文件，扩展程序在已连接的浏览器配置文件中操作，而 MCP 服务器则自带浏览器和权限模型。

下面按文档原文列出每条路径能做什么、不能做什么。如果只记一件事，请记住配置文件的边界：内置浏览器与你日常使用的浏览器相互独立，而扩展程序只在你授权的配置文件和标签页中操作。很多 Codex 浏览器故障，都是因为让一条路径去做了另一条路径的事。

如何安装 Codex Chrome 扩展？

请从 ChatGPT 桌面应用安装，这样应用、原生连接、浏览器扩展和配置文件会通过同一条受支持的流程完成配对。打开 Settings > Computer use，如有需要展开 More browsers，选择 Google Chrome，然后按提示操作。点击 Install 打开浏览器的扩展商店，查看所请求的权限，完成安装，再回到 Computer use 确认该浏览器已显示 Manage。

OpenAI 的computer-use 指南展示了桌面端权限界面，已连接的浏览器会出现在这里。桌面端权限和浏览器扩展自身的站点访问权限都要检查，两者不能互相替代。

1. 开始前先更新 ChatGPT 桌面应用；如果你安装了多个桌面副本，请把每一个都更新。
2. 把扩展安装到 Codex 实际要使用的那个浏览器配置文件中，然后从浏览器工具栏重新打开 ChatGPT，确认侧边聊天能正常加载。
3. 回到 Settings > Computer use，确认已显示 Manage，然后打开浏览器开关，让它出现在 @ 提及菜单中。
4. 新建一个 ChatGPT Work 或 Codex 对话，提及 @Chrome，先在一个可信站点上发起只读请求。

路径 1：内置浏览器（@Browser）

它是什么：一个内嵌在 ChatGPT 桌面应用（以及网页版）中的浏览器，让你和模型获得“在对话中共享网站和本地 Web 应用的视图”。从 Plugins 标签页启用它，用 @Browser 或 Cmd+Shift+B 调用，Computer Use 让 Codex 能针对你们共同看到的页面“打开页面、点击、输入、检查渲染状态、截图”。

它的开发者体验比多数人预期的更好：可以预览本地开发服务器，支持在页面元素上做可视化标注（Adjust 选项能给出细粒度的样式反馈），还有一个 Developer mode 可授予“对 Chrome DevTools Protocol 的受控访问”，用于 console、network 和 DOM 检查，但需要显式批准才能开启，因为 CDP“可能暴露敏感的浏览器内部信息”。

按照官方文档，它的边界是：它运行的是“一个与你的常规浏览器相互独立的浏览器配置文件”，所以你的任何会话都不在其中；它“无法自动上传文件”；而且它“在 Codex CLI 和 Codex IDE 扩展程序中不可用”，这一点最让习惯用 CLI 的开发者意外。把它看作演示和预览的界面，而不是执行任务的界面。

Codex 浏览器扩展是如何工作的？

它是什么：通过浏览器扩展程序进入你真实浏览器配置文件的路径。从桌面应用安装它，新建一个 ChatGPT Work 或 Codex 对话，然后用 @ 提及选中已连接的浏览器。之后 Codex 就能在以下站点上执行操作：“你已登录的站点，例如 LinkedIn、Salesforce、Gmail 或内部工具”，并且你可以提及某个打开的标签页，把该页面作为上下文。

权限模型基于主机名：OpenAI 会在首次与某个新网站交互前询问，你可以选择仅允许一次，也可以为该站点持久授权。文档指出，要把网页内容、选中的文本和视频字幕都视为不可信上下文。批准之前，先检查站点和请求的操作。该扩展程序目前支持 Chrome、Edge、Brave、Opera 和 Vivaldi；Opera 没有侧边聊天，但仍可从桌面应用中选择。

实际的分工在于配置文件状态：@Browser 打开的是内置浏览器，而 @Chrome 选中的是你所连接的那个 Chrome 配置文件里已安装的扩展程序。完整的 CDP 开发者访问权限是一项独立的高风险设置，需要显式批准后 Codex 才能检查某个站点。

路径 3：MCP 服务器

它是什么：Codex 支持 MCP，所以任何浏览器服务器都能用一条命令接入：

codex mcp add playwright -- npx "@playwright/mcp@latest"
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

这是可扩展的路径，它继承每个服务器各自的配置文件和权限模型：Playwright MCP 带来跨浏览器自动化，以及快照上下文的取舍；Chrome DevTools MCP 带来性能追踪，并且通过自动连接，让你已登录的 Chrome 共享同一个窗口；Browser MCP 则以协议参与者的身份带来扩展程序式的接管能力。

我们在Claude Code 浏览器 MCP 评分表中的所有内容在这里原样适用，因为这些服务器是同一批，只是换了客户端。

MCP 路径对 Codex 用户独有的价值：摆脱单一厂商的设计决策。它做不到的：没有任何一个服务器能同时具备你的登录态、独立窗口和精简的 Token 消耗。这三者的组合正是下面这张对比表要暴露出来的缺口。

这三条路径如何对比？

三个维度决定日常使用；第四行则是所有路径都填不上的那一项。

最后一行是外部浏览器方案：ego (lite) 在 Space（隔离空间）中运行 Agent 任务，完全不会碰到你正在使用的标签页。

这一行背后有一个数据点：在 Real-World Bench 上，用同一个模型（gpt-5.6-sol）和同一套评判标准，对真实生产站点跑了 31 个任务，测试时间为 2026 年 8 月 19 日（任务包括从联邦案卷中整理出一份 CourtListener 诉讼档案，以及找出八周内周五出发、周日返回的最便宜 Google Flights 组合），ego (lite) 完美完成了 31 个任务中的 93.5%，是所测五款工具中最好的结果。该结果只描述这次基准测试的配置和任务集，不代表所有浏览器工作负载。完整任务集和评判代码在 GitHub 上。

在我们另一项 heredoc 与 REPL 的对比基准测试中，整段脚本执行完成相同任务所用的执行轮次少了 44%，工具调用次数少了 35.5%，成本比逐条命令执行低 21.6%。这些数字来自那次记录下来的工作流，并不构成通用的省钱保证。相比三条官方路径，ego (lite) 缺少的是：@Browser 在对话内共享视图和标注的流程，以及扩展程序更简单的安装配置路径。

“精简 Token”这一说法是一项对比，而不是绕到路径 3。下面是 ego (lite) 返回的定向提取结果，来自一次针对 Hacker News 的记录会话：

ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
console.log({ taskSpaceId: task.id })

await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)
console.log({ title, url: task.page.url(), topStory, points })
EOF

# real output
{
  "taskSpaceId": 13
}
{
  "title": "Hacker News",
  "url": "https://news.ycombinator.com/",
  "topStory": "Qwen 3.8 27B",
  "points": "412 points"
}

返回给 Agent 的约 150 个字符。对于同一个页面，我们通过 Chrome DevTools MCP 测得的 take_snapshot（不同的服务器，但与 Playwright MCP 采用相同的“每动作一次快照”设计）运行了 38,285 个字符。这就是表格最后一行所衡量的 Token 差距。

不同用途该选哪条路径？

按你正在做的事来选，因为选择就是这样出现的。验证你正在写的代码（预览、视觉检查、样式反馈）：选 @Browser，它正是为这种共享视图循环而构建的，包含 CDP 开发模式。

偶尔在你账号中执行任务，只需一次性配置扩展程序：用 @ 提及选择已连接的浏览器。测试基础设施、自定义浏览器服务器，或集成工作流之外的深度调试，则指向 MCP。

需要与日常浏览器隔离的登录态日常任务：用 ego (lite)，Agent 继承你真实的登录信息并在自己的 Space 中运行，你继续使用自己的窗口。并行任务仍受账号、站点和机器限制。

某一天，四种全用上，以展示它们相互组合而非相互竞争：早上，@Browser 预览你要发布的分支并标注间距问题；中午，Playwright MCP 对修复运行跨浏览器检查。

下午，一个配置好的外部浏览器在独立的 Space 中从三个已授权的仪表盘拉取本周数据，而你同时在审阅 PR；晚上，@Chrome 在你的会计门户中提交报销单，因为这只是单个任务，而扩展程序已经在那里了。每个操作仍然需要账号权限，以及与其风险相称的人工审核。

详细了解 ego (lite) 与 Codex 浏览器的对比，或者 免费下载 Mac 版 ego (lite).

Codex 浏览器控制失败如何排查？

先确定是哪个界面失败了，然后把任务缩减到一个页面和一个动作。内置 Browser 失败、Chrome 扩展程序失败和 MCP 超时各有不同的责任方和日志；一次性重装所有东西通常会掩盖原因。记录确切的报错、Codex 界面、操作系统、浏览器版本、URL，以及该动作是否需要登录或上传文件。

1. 确认界面和前置条件。 仅在暴露集成浏览器的界面中使用 @Browser。仅当桌面应用的 Computer use 设置中，当前浏览器配置文件（Profile）显示 Manage，且目标站点已被允许时，才使用 @Chrome。在支持该服务器的客户端中使用 MCP，并检查服务器进程能否在 Codex 之外启动。
2. 先测试一个公开的静态页面。 如果公开页面能正常操作，而内部页面失败，那么问题边界大概率在身份验证、企业策略、网络访问或站点权限上，而不是点击本身。如果所有页面都失败，先检查本地进程、扩展程序状态和客户端日志，再去改提示词。
3. 把临时性错误和权限错误区分开。 对于启动竞态或临时网络超时，可以设置一个有限延迟重试一次。但遇到 401、403、域名被屏蔽、验证码（CAPTCHA）、缺少审批或账号警告时，不要循环重试。这些响应需要新的权限、人工交接，或换一条受支持的路径。
4. 检查最终状态，而不是模型的叙述。 要求给出结果 URL、可见的确认信息、下载文件名或其他可验证的产物。模型说表单已提交，并不等于服务器接受了它。

在 Windows 上遇到 Chrome 控制运行时或 RPC 报错时，把诊断范围收窄：从可信来源更新 Codex 应用和扩展程序，重启原生宿主，确认扩展程序在当前浏览器配置文件（Profile）中已启用，并用一个无害的公开页面复现。不要为了让浏览器控制启动就关闭 Defender 或绕过信任检查；不受信任的运行时可能暴露整个配置文件。

如何在远程或无头服务器上完成 Codex 认证？

远程 Codex 身份验证，本质上是在交互式浏览器登录、API key 或企业批准的身份流程之间做选择。无头浏览器不可能凭空完成 loopback OAuth 回调：要在可信设备上完成验证，在支持时使用文档说明的远程连接或设备流程，或通过宿主机的密钥管理器提供一个限定范围的密钥。不要把浏览器 Cookie、refresh token 或认证文件复制到不受信任的服务器上。

• 交互式 CLI 登录。 在回调能打开的机器上运行受支持的 Codex 登录命令。如果是远程 shell，使用该环境文档说明的交接或端口转发方式，并在批准前验证重定向主机。
• API 身份验证。 仅在账号和组织策略允许的地方使用 API key。把它作为运行时密钥注入，限制其所属项目和消费额度，并让它远离 shell 历史、源码管理、提示词、截图和任务输出。
• MCP OAuth。 对于远程 MCP 服务器，配置服务器 URL，并在服务器声明支持 OAuth 时使用 codex mcp login <server-name>。注册提供商要求的确切回调地址；MCP 连接成功并不意味着能获得该服务器工具之外的浏览器访问权限。

如果 OAuth 在托管 IDE 或 Replit 风格的容器中循环跳转，检查执行登录的浏览器能否访问 localhost、回调端口是否已转发，以及提供商是否拒绝该重定向 URI。修复这个拓扑问题，或改用受支持的设备/API 流程；不要试图从浏览器配置文件中查找或导出 refresh token。

Codex 用量上限与浏览器 Token 消耗是怎么算的？

Codex 的浏览器操作消耗的是实际运行它的界面和模型所对应的用量上限与计费规则；不存在适用于所有方案的统一浏览器 Token 价格。一段长时间的 computer-use 轨迹、反复截图或大型 MCP 快照，消耗的上下文可能远多于一次简短的 DOM 提取。查看当前方案的用量页面和组织的消费控制，而不是从单个任务推断配额。

• 执行前先做预算。 为周期性任务设置最大操作次数、时间限制和消费告警。把宽泛的研究请求拆成有边界的任务，避免一次循环耗尽全部额度。
• 缩小观察数据量。 优先使用具名定位器、表格片段或 API 响应，而不是完整截图或无障碍快照。把页面状态留在浏览器里，只返回下一步需要的字段。
• 确定性的工作用确定性的步骤。 重复的导航和解析可以交给 Playwright 或 shell 脚本，Codex 负责处理模糊决策或恢复。这通常比让模型叙述每一次点击更省。
• 衡量被接受的结果。 按每条被接受的数据行或每个完成的工作流，跟踪输入和输出 Token、浏览器耗时、重试次数、失败操作和人工修复量。一次触发频率限制或需要人工重做的运行，不算低成本的成功。

如果一条普通提示词突然消耗了远超预期的配额，检查模型选择、上下文长度、附加的轨迹、MCP 快照、重试和并行任务。先暂停队列，再用最小复现和原始运行做对比；轮换 key 或开更多账号，并不是解决工作负载过大的可靠办法。

在主用机器上使用 Codex 浏览器和电脑操作安全吗？

把它当作一个有特权的助手来对待会更安全：使用独立的浏览器配置文件、明确的审批和可逆的任务，而不是把它当作可信用户。浏览器页面是不可信的输入，可能包含提示词注入。主机器可能暴露 Cookie、文件、消息账号和支付入口，所以在工作流允许时，使用独立的操作系统配置文件或浏览器配置文件、最小权限凭证，并对产生外部副作用的操作要求人工审批。

• 限制 Agent 能触及的范围。 使用独立的浏览器配置文件或 Space（隔离空间），只允许需要的域名和标签页，避免在一次运行中混用个人邮箱、密码管理器、管理控制台和支付账号。
• 对重要操作要求审批。 在发送消息、更改权限、购买、删除、发布，或提交具有法律、财务影响的表单之前，先暂停确认。
• 保护证据与机密信息。 检查截图、DOM 快照、提示词、模型请求、下载内容和日志分别存放在哪里。分享 trace 之前先脱敏，并按你的合规策略设置保留期限。

隔离能缩小影响范围，但并不能让 Agent 免疫注入攻击。VPN、本地模型、密码管理器或本地浏览器本身，都无法阻止恶意页面影响模型，也无法阻止已获批准的工具执行有害操作。请用不可信内容测试整个工作流，并把终止开关和凭证吊销路径放在 Agent 之外。

企业网络和反机器人限制会怎样影响 Codex？

企业代理、TLS 检查、浏览器策略、域名封禁、频率限制和反机器人检测，都可能在人类能正常打开页面的情况下拦住 Codex。要把这些当作访问与授权边界来诊断。不要为了强行拿到结果而关闭企业安全控制、伪造指纹、轮换身份、重放 Cookie 或自动破解验证码（CAPTCHA）。

1. 检查策略与网络路径。 向管理员确认该域名、WebSocket、native host、MCP 端点或 CDP 端口是否被允许。在已批准的浏览器和 Codex 界面上分别打开同一个 URL 做对比，注意不要暴露凭证。
2. 对返回结果分类。 证书或代理错误属于网络管理方；域名被封禁的提示属于策略问题；401 或 403 属于站点或账号问题；验证码（CAPTCHA）或人机挑战是停止信号，除非站点提供了经批准的人工通道。
3. 选择合规的替代方案。 改用官方 API、导出、数据合作或人工审核。做公开研究时，走受支持的未登录路径，并遵守 robots.txt、服务条款和频率限制。

如果 Discord、LinkedIn 或其他服务发出自动化警告，请停止该工作流，并检查其规则和账号状态。浏览器 Agent 无法保证账号不被限制，一次技术上成功的点击，并不等于你有权发送未经请求的消息或抓取受保护的数据。

如何把 Codex 连接到 DevTools 和 MCP 浏览器服务器？

当 Codex 需要内置 Browser 或 Chrome 扩展无法提供的浏览器服务器时，走 MCP 路线。一次只添加一个服务器，从它最窄的工具集开始，检查服务器列表，只在必要时才做认证。Chrome DevTools MCP 适合调试和性能检查；Playwright MCP 适合跨浏览器操作与断言；两者都不会自动继承与 @Chrome 相同的浏览器配置文件（Profile）或权限模型。

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest
codex mcp add playwright -- npx "@playwright/mcp@latest"
codex mcp list
codex mcp login <server-name>

本地服务器：添加之前先确认命令和工作目录。远程服务器：确认 HTTPS 端点、OAuth issuer、scopes 和回调 URL。机密信息放在环境变量或已配置的密钥来源中；不要把 bearer Token 粘贴进会提交到仓库的 TOML 文件。

• DevTools 服务器超时怎么办。 确认浏览器是以预期的调试连接启动的，端口只能从预期主机访问，并且没有其他进程占用该浏览器配置文件（Profile）。CDP 端点属于敏感的浏览器访问入口，不是公开服务。
• MCP 服务器开销太大怎么办。 关闭用不到的工具，只请求聚焦的定位或数据提取，重复性任务优先用确定性的 CLI。上下文里只保留当前工作流需要的服务器。

哪些 Codex 浏览器扩展和环境是兼容的？

兼容性取决于具体路径和当前的桌面端集成。内置 Browser 属于受支持的 ChatGPT 应用界面。浏览器扩展目前支持 Chrome、Edge、Brave、Opera 和 Vivaldi，其中 Opera 没有侧边聊天。Codex CLI 和 IDE 扩展不提供集成浏览器功能；外部 MCP 工具则各自有自己的支持范围和权限约定。

• Chrome 扩展缺失，或已连接但处于空闲状态。 确认桌面组件和 Web Store 扩展程序都是从官方来源安装的，当前激活的浏览器配置文件就是你授权过的那个，扩展程序在当前标签页已启用，且该站点没有被策略封禁。更改权限后重新打开标签页。
• 浏览器或 PDF 阅读器界面无法访问。 把扩展程序页面、浏览器设置、特权 chrome:// URL 和内嵌 PDF 阅读器视为彼此独立的界面。当集成没有暴露该界面时，改用导出的文件、可访问的网页，或受支持的 MCP/CLI 工作流。
• Windows 或 Linux 与 macOS 表现不同。 查阅当前的 Codex 支持矩阵、沙箱与权限要求、native host 安装方式以及操作系统安全策略。不要假设 macOS 上的命令、路径或浏览器配置文件在 Windows、WSL、容器或 VPS 上可以原样使用。

当需求是一个独立于 Codex 窗口、能保持登录态的浏览器时，就用 ego (lite)，让 Codex 继续充当规划或审查层。ego (lite) 本身就是浏览器，因此不需要为每个浏览器配置文件安装扩展程序，不需要反复授予逐站点授权，也没有连接需要保活或等待空闲。

常见问题

为什么 Codex CLI 不能用内置浏览器？

内置浏览器存在于 ChatGPT 应用界面中；OpenAI 的文档指出它“在 Codex CLI 或 Codex IDE 扩展程序中不可用”。想用浏览器操作的 CLI 用户，可以走 MCP 路径，或者用 ego (lite)，任何编码 CLI Agent 都能通过开源的 ego-browser shell 连接，无需 SDK。

我看到的 Cloud browser 是什么？

还有第四种更窄的形态：一个远程托管的浏览器，用于网页版 ChatGPT Work，它仅支持公开的、未登录的网站，不支持登录、本地标签页或扩展程序，且可用性取决于套餐。适合在网页应用里做公开资料调研；但它不是通往你账号的路径。

可以同时使用 Playwright MCP 和扩展程序吗？

可以；两者占用的位置不同（MCP 配置与 Chrome 扩展程序），不会冲突。一种常见的 Codex 配置正是这一对组合：MCP 负责测试类工作，扩展程序负责账号类任务，同时要注意别加载太多 MCP 工具 schema。

如何启用内置浏览器的开发者模式？

依次进入 Settings、Browser、Enable full CDP access，会有一个明确的批准步骤，因为 CDP“可能暴露浏览器的敏感内部信息”。管理员可以在 requirements.toml 中用 browser_use_full_cdp_access = false 在整个组织范围内禁用。开启后，Codex 可以在内置浏览器中分析 JavaScript，并检查 console、network 和 DOM。

大家搜索 codex chrome mcp 时，指的到底是什么？

通常是把两种配置混成了一个说法：要么是把 Chrome DevTools MCP 加到 Codex 中（codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest），要么是在 Codex 任务中使用 ChatGPT 浏览器扩展程序。扩展程序不是 MCP 服务器。需要可配置的调试服务器时用 DevTools MCP；需要 Codex 在你通过桌面应用连接的浏览器配置文件中操作时，用扩展程序。

这些功能有不付费就能用的吗？

扩展程序和内置浏览器沿用你的 ChatGPT 套餐及其用量上限。MCP 服务器软件本身可能免费安装，但模型、托管和浏览器服务商仍可能产生费用。使用 ego (lite) 时，页面以无障碍树快照而非原始 HTML 的形式交给 Agent，因此任务整体消耗的 Token 往往更少；你搭配使用的模型和 Codex 访问权限，仍受各自的套餐、用量上限和服务商条款约束。