# Codex Browser 与 Chrome 技能调研记录

日期：2026-06-26  
主题：Codex 内置浏览器、外置 Chromium 浏览器扩展、登录态页面操作与自动化测试的能力边界  
性质：讨论整理与后续 Skill 设计参考，不是正式安全政策或项目规范

## 1. 摘要结论

今天的实测可以归纳为一句话：

> `browser` 适合干净、后台、可重复的网页自动化；`chrome` 适合需要真实浏览器 profile、登录态、扩展环境和用户可见页面的任务。

二者不是互相替代关系，而是不同执行表面：

| 维度 | browser | chrome |
| --- | --- | --- |
| 浏览器位置 | Codex 内置浏览器 | 外置 Chromium 浏览器，通过扩展连接 |
| 用户是否能看到 | 默认后台；需要时可显式显示 | 用户能在 Edge/Chrome 等真实窗口中看到 |
| 登录态 | 默认没有用户真实 Cookie/session | 使用当前浏览器 profile 的登录态 |
| 适合任务 | 本地 Web 测试、公开页面检查、干净环境验证 | 已登录网站操作、接管当前标签、需要扩展或真实账号的流程 |
| 隐私边界 | 与用户真实浏览器隔离 | 可读页面显示内容，但不应读取原始 Cookie、localStorage、密码或 session store |
| 主要风险 | 隐式后台操作、WebAuthn 系统弹窗可能让用户困惑 | 真实账号误操作、隐私内容暴露、对站点规则的合规风险 |

## 2. 本次实测事实

### 2.1 browser 内置浏览器

本次用 Codex 内置浏览器访问 `https://x.com`，页面成功加载，得到的状态包括：

- URL：`https://x.com/`
- 标题：`X. It's what's happening / X`
- 页面状态：`complete`
- 页面文本包含未登录首页的登录选项

这说明 `browser` 不限于 `localhost`。技能说明中强调 `localhost`、`127.0.0.1`、`file://`，是因为它常用于本地 Web 应用测试，而不是访问权限只允许本地页面。

需要注意：`browser` 默认在后台运行。用户不一定能看到它的窗口。如果任务目标是“让用户看见页面”或“边看边操作”，需要显式使用可见性能力把内置浏览器展示出来。

本次访问 X 时，Windows 弹出了 Passkey/WebAuthn 安全密钥提示。这个提示来自系统认证层，即使浏览器本体在后台，也可能弹到用户桌面。除非用户明确要完成登录，否则这类认证提示应取消或等待用户处理。

### 2.2 chrome 外置浏览器扩展

最初 Chrome 技能环境不可用，报错为扩展后端不可用。后来用户在 Edge 中安装了对应扩展后，扩展通道可用。

随后通过 `chrome` 技能完成了几项验证：

- 连接到外置 Chromium 浏览器扩展后端。
- 打开 `https://x.com`。
- 使用用户真实浏览器 profile 中的 X 登录态进入 `https://x.com/home`。
- 接管 X 标签页，在右侧 `What is happening` 区域找到标题 `見てるだけでいいの`。
- 点击该标题，页面进入搜索页：
  - `https://x.com/search?q=見てるだけでいいの&src=promoted_trend_click&vertical=trends`
  - 标题变为：`見てるだけでいいの - Search / X`

这说明虽然技能名是 `chrome`，但本次实际可用的是 Edge 上的 Chromium 扩展通道。更保守的表述应是：`chrome` 技能控制的是安装并连通 Codex 扩展的外置 Chromium 浏览器/profile，而不是只能控制 Google Chrome。

### 2.3 标签页可见性边界

通过外置浏览器扩展，Codex 可以列出当前连接 profile 中的顶层标签页元数据，例如：

- 标题
- URL
- 最近打开或聚焦时间
- 标签组信息

但这不等于自动读取所有页面内容。只有在接管某个标签页之后，Codex 才会读取该页 DOM、可见文本、截图并执行点击、输入等操作。

它也不等于能看见整台机器：

- 看不到未安装或未启用扩展的浏览器。
- 看不到其他浏览器，例如 Firefox。
- 看不到其他未连接的 profile。
- 无痕窗口通常需要额外允许扩展后才可能被看到。
- 不应读取原始 Cookie、localStorage、密码、session store。

## 3. 能力模型

可以把浏览器自动化分成三层：

### 3.1 连接层

连接层决定 Codex 能否拿到浏览器控制面：

- `browser`：连接 Codex 内置浏览器，后端为 `iab`。
- `chrome`：连接外置浏览器扩展，后端为 `extension`。

连接层只说明“能不能控制浏览器”，不说明“该不该操作某个账号页面”。

### 3.2 页面层

页面层决定 Codex 能读到什么：

- 页面标题、URL、DOM、可见文本、截图。
- 页面上已渲染出来的登录态内容。
- 用户当前能正常访问的网页内容。

页面层不等于底层凭证层。已经渲染在页面上的用户名、头像、消息、列表等可以被读到；但原始 Cookie、浏览器密码、session 文件不应读取。

### 3.3 操作层

操作层决定 Codex 能做什么：

- 点击链接、按钮、标签页。
- 输入表单。
- 滚动页面。
- 截图。
- 提取可见文本。
- 读取少量 DOM 状态。

有外部副作用的动作需要额外确认，例如：

- 发帖、评论、私信。
- 点赞、关注、收藏。
- 提交表单。
- 上传文件。
- 改权限。
- 购买、支付。
- 删除数据。
- 接受敏感浏览器权限。

## 4. 场景判断

### 4.1 防爬网站与内容采集

用户提出“小红书这类防爬网站，是否可以利用 chrome 打开页面，爬取对应文章和视频”。

判断：技术上可以做一部分，但必须把“浏览器辅助整理”与“绕过反爬爬虫”区分开。

适合做：

- 打开用户账号本来就能看到的页面。
- 少量、低频、人工授权范围内的内容整理。
- 提取标题、正文、作者、时间、链接等页面可见信息。
- 生成摘要、标签、笔记、引用清单。
- 截图保存证据。
- 对用户自有内容或明确授权内容做归档。

不适合做：

- 批量绕过反爬。
- 绕过验证码、风控、登录限制。
- 绕过付费墙、年龄验证、地区限制。
- 绕过 DRM 或下载受保护视频。
- 批量搬运有版权风险的内容。
- 抓取私密、敏感、未授权内容。

对于视频内容，应优先记录页面 URL、标题、作者、发布时间、可见描述、封面和引用信息。只有在用户明确拥有权利或站点明确允许下载时，才考虑下载或保存媒体文件。

### 4.2 Web 系统自动化测试

用户总结“Web 系统自动化测试完全可以用 browser，这种不需要人工介入，也省开销”。

判断：准确，但应补充一个路由条件。

优先使用 `browser` 的测试场景：

- 本地开发服务：`localhost`、`127.0.0.1`。
- 未登录或测试账号流程。
- 表单提交、按钮点击、弹窗验证。
- 布局和响应式检查。
- 截图回归检查。
- 控制台错误检查。
- 干净环境复现 bug。
- 不依赖真实账号、真实扩展、真实浏览器 profile 的测试。

应使用 `chrome` 的测试场景：

- 依赖真实登录态。
- 依赖企业 SSO。
- 依赖 Passkey、2FA 或用户手动认证后的会话。
- 依赖浏览器扩展。
- 需要接管用户当前已打开的生产后台页面。
- 需要用户看着真实浏览器页面确认操作结果。

工程化建议：长期稳定的 E2E 测试仍应沉淀到项目内 Playwright、Cypress 或类似测试框架。Codex 的 `browser` 更适合探索式测试、回归前人工智能辅助检查、临时验证和生成测试线索。

## 5. 路由规则草案

后续如果要做项目内 Skill，可以把路由规则写成以下形式。

### 5.1 默认选择 browser

当满足以下条件时，默认使用 `browser`：

- 目标是本地 Web 应用或公开页面。
- 不需要用户真实登录态。
- 不需要浏览器扩展。
- 不需要用户观看过程。
- 操作无账号副作用。
- 目标是验证行为、提取公开信息、截图、检查 UI。

### 5.2 选择 chrome

当满足以下任一条件时，使用 `chrome`：

- 用户明确要求使用 Edge、Chrome 或外置浏览器。
- 需要用户当前登录态。
- 需要接管已打开标签页。
- 需要浏览器扩展或真实 profile。
- 需要用户看到页面。
- 页面被登录、SSO、2FA、Passkey、企业权限挡住，而用户已经在真实浏览器中完成认证。

### 5.3 暂停并确认

当任务包含以下动作时，应暂停并确认：

- 发帖、评论、私信、关注、点赞、收藏。
- 提交会改变外部系统状态的表单。
- 上传个人文件。
- 下载或保存可能受版权保护的媒体。
- 输入或提交密码、验证码、API key、支付信息、身份证件、地址、医疗或财务信息。
- 接受摄像头、麦克风、定位、下载、扩展安装等浏览器权限。
- 遇到 CAPTCHA 或安全验证。

### 5.4 拒绝或改为安全替代

当任务意图是绕过访问控制、批量规避反爬、破解 DRM、绕过付费墙、抓取未授权私密内容时，不应执行。可替代方案是：

- 只整理用户手动提供或合法可访问的页面。
- 只做摘要、索引、引用清单。
- 使用官方 API、导出功能或平台允许的下载方式。
- 降低频率，保留来源链接，不做批量复制。

## 6. Skill 设计建议

如果在项目库中打造对应 Skill，建议不要做成“浏览器操作说明”的简单封装，而应做成一个路由与安全边界 Skill。

### 6.1 建议名称

可选名称：

- `browser-surface-router`
- `codex-browser-routing`
- `web-automation-surface-policy`
- `logged-in-browser-automation`

如果面向中文项目库，建议名为：

- `浏览器执行表面路由`
- `网页登录态自动化边界`
- `Codex Browser Chrome 路由规则`

### 6.2 Skill 输入判断项

每次执行前先判断：

```text
target_url_or_app:
requires_real_login_state: yes/no
requires_existing_tab: yes/no
requires_browser_extension: yes/no
user_must_watch: yes/no
operation_type: read/click/type/download/upload/submit/change_permission
external_side_effect: yes/no
sensitive_data_involved: yes/no
anti_bot_or_access_control_present: yes/no
expected_artifact: summary/screenshot/extracted_text/test_result/navigation
```

### 6.3 输出格式

Skill 可以要求 Codex 输出：

```text
Selected surface: browser | chrome | stop-and-confirm | refuse-with-safe-alternative
Reason:
Risk flags:
Allowed actions:
Disallowed actions:
Verification plan:
Cleanup plan:
```

### 6.4 操作原则

建议沉淀以下原则：

1. 优先干净环境：能用 `browser` 就不用真实账号。
2. 真实账号最小化：只有需要登录态、扩展或用户可见页面时才用 `chrome`。
3. 不读底层凭证：不读取 Cookie、localStorage、密码、session 文件。
4. 页面内容可读但需谨慎：已渲染页面内容可用于任务，但敏感信息不应扩散。
5. 外部副作用动作前确认：提交、发送、上传、购买、删除、改权限都要确认。
6. 防爬场景不做绕过：只做合法访问范围内的低频整理、摘要和引用。
7. 测试场景优先工程化：探索式测试可用 Codex，稳定回归应进入项目测试框架。

## 7. 可复用决策表

| 任务 | 推荐表面 | 说明 |
| --- | --- | --- |
| 本地前端页面冒烟测试 | browser | 干净、后台、可重复 |
| 检查 `localhost` 登录弹窗是否出现 | browser | 除非必须使用真实 SSO |
| 需要企业 SSO 后台 | chrome | 依赖真实浏览器登录态 |
| 用户已在 Edge 打开的 X 页面操作 | chrome | 接管指定标签页 |
| 抓取公开网页标题和正文 | browser | 不需要真实账号 |
| 整理用户账号可见的小红书笔记 | chrome | 低频、授权、只取可见内容 |
| 批量下载小红书视频 | stop/refuse | 可能涉及反爬、版权和平台规则 |
| 生成 UI 截图证据 | browser | 默认后台，必要时显示 |
| 复现只有用户浏览器才出现的问题 | chrome | 依赖真实 profile 和扩展 |
| 需要点击“提交订单” | confirm | 外部副作用动作 |

## 8. 对未来项目库的落地建议

建议在具体项目库中不要把这份记录直接当运行规则全文复制，而是提炼为三类文件：

```text
skills/
  browser-surface-router/
    SKILL.md
    references/
      browser-vs-chrome-research.md
      safety-boundaries.md
    templates/
      task-routing-checklist.md
```

`SKILL.md` 应保持短而可执行，只放触发条件、路由规则、确认规则和输出格式。本文这种调研记录更适合作为 `references/` 下的背景材料。

对于需要频繁采集资料的项目，可再拆一个专门 Skill：

```text
skills/
  logged-in-page-extraction/
    SKILL.md
    references/
      allowed-extraction-patterns.md
      disallowed-anti-bot-patterns.md
```

它的核心不应是“怎样绕过反爬”，而应是“怎样在用户授权和平台允许的范围内，把用户可见页面整理成结构化材料”。

## 9. 未解决问题

后续还需要进一步验证：

- Codex 内置 `browser` 的可见模式在当前 Windows 桌面中的具体表现。
- Edge、Chrome、多 profile、无痕窗口的扩展连接边界。
- 对视频页面，能稳定提取哪些层级的信息：页面元数据、封面、可见描述、播放状态、媒体 URL。
- 对项目内 Web 系统，`browser` 结果如何转化为正式 Playwright/Cypress 测试。
- 如何在团队或个人知识库中记录“已授权页面采集”的证据和范围。

## 10. 一句话规则

后续做 Skill 时可以把核心规则压缩成：

> 默认用 `browser` 做干净、后台、可重复的网页验证；只有当任务确实依赖用户真实浏览器状态、登录态、扩展或可见窗口时，才使用 `chrome`；任何外部副作用、敏感数据、验证码、反爬规避、版权下载都必须停下来重新确认或改用安全替代方案。