讨论：是否为侧边浏览器复用用户 Chrome 登录态而开发 Chrome 扩展

## 背景

侧边浏览器目前无法复用用户日常 Chrome 的登录态，用户在自己 Chrome 里登录过的网站（Gmail、内部系统等）在侧栏里要重新登一遍。对标 OpenAI Codex 的侧边栏——它能直接使用用户 Chrome 的登录会话。

本 issue 的目的是**决策**：要不要为了这件事去做一个我们自己的 Chrome 扩展。不是实现 issue，而是先对齐是否立项、走哪条路线。

## 现状：为什么我们读不到

侧边浏览器内核是 vendored 的 openclaw（`packages/browser-control-runtime`），底层 playwright-core + CDP。它启动 Chrome 时用**自建的独立 user-data-dir**（`buildOpenClawChromeLaunchArgs`：`--user-data-dir=/browser/XDMaker/user-data`）并带 `--disable-sync`。这是一个专属、持久、与用户日常 Chrome 完全隔离的 profile——cookie 和登录态各存各的。隔离是有意设计（可控、干净），代价就是登录态不共享。

## Codex 是怎么做到的

Codex 不自建浏览器，而是发布**官方 Chrome 扩展**装进用户**真实的 Chrome**：

- 扩展 background service worker 用 `chrome.debugger` API（需用户显式授权的特权 API）attach 到用户当前 tab，拿到该 tab 的 CDP 会话；
- 拿到 CDP 后即可读 DOM、控制页面、看网络/console；
- 扩展与桌面 app 之间通过 **Chrome native messaging host** 通信（扩展权限含"与协作的本地应用通信"，故障排查提到"缺少 native host"）。

因为整套跑在用户真实 Chrome 的同一个 profile 里，天然继承所有 cookie 和已登录会话——这就是"直接读 Chrome 登录态"的本质。

硬约束（Chrome 的安全设计，无法绕过）：

- 只支持 **Chrome**，其它 Chromium 浏览器不行，且必须是装了扩展的那个 profile；
- attach 时 Chrome 会弹"XX 正在调试此浏览器"横幅，**压不掉**；
- 需要用户主动装扩展并授权。

参考：
- https://learn.chatgpt.com/docs/chrome-extension
- https://developers.openai.com/codex/app/browser

## 我们能不能做——能，而且内核已经走了一半

关键利好：**我们的 CDP 内核已经支持"连接到现成的外部 CDP 端点"**，不是只会自己 spawn。vendored 代码里 profile 支持配 `cdpUrl`（`profiles.ts`、`config-mutations.ts` 的 `parsedCdpUrl` + `assertCdpEndpointAllowed`），Playwright 层能 `connectOverCDP` 到指定端点。所以"拿到用户 Chrome 的 CDP 后驱动页面"这段不用重写，缺的只是**把用户真实 Chrome 的 CDP 暴露出来的那条前置桥**。

### 路线 A —— 复刻 Codex（扩展 + native host），体验最好、工作量最大

做一个我们自己的 Chrome 扩展，用 `chrome.debugger` attach 用户 tab，通过 native messaging host（或本地 WebSocket）把 CDP 桥回桌面 app，app 侧用现有内核的 `cdpUrl` 接上。需要的新基建：

1. 一个上架/企业分发的 Chrome 扩展；
2. 系统注册 native messaging host manifest，指向 app 的一个入口；
3. 配对/授权握手。

约束同 Codex：只 Chrome、有调试横幅、要用户装扩展。

### 路线 B —— connectOverCDP 到用户手动开调试端口的 Chrome，几乎零内核开发

让用户用 `--remote-debugging-port=` 启动 Chrome，我们直接 `connectOverCDP` 连上。内核现成支持，基本只要在设置里加"连接到我的 Chrome"入口。缺点：用户得以特殊参数重开 Chrome、开着调试端口有安全顾虑，体验远不如 Codex。适合先做**可行性验证**。

### 路线 C —— 不读 Chrome 登录态，只解决登录痛点

保持独立 profile，用注入层 + 1Password/Bitwarden CLI 做显式填充。不"读 Chrome 登录态"而是绕过它，成本中等、跨密码管理器通用。

## 核心决策点（待讨论）

1. **要不要为此立项做 Chrome 扩展（路线 A）？** 这是本 issue 的核心问题。
2. **能否接受两个硬约束**：用户必须装扩展 + Chrome 常驻"正在调试此浏览器"横幅？这直接决定产品体验能否被接受。
3. **只支持 Chrome 是否够**（Edge / Arc / Brave 等 Chromium 用户覆盖不到）？
4. **分发方式**：Chrome Web Store 上架（需审核、公开）还是企业/开发者模式分发？
5. **优先级与替代**：是否先用**路线 B 做一次 `connectOverCDP` 到外部 Chrome 的可行性验证**（改动很小），把"内核到底支持到什么程度"从推断变成实测，再决定是否投路线 A？路线 C 是否作为并行的兜底方案？

## 建议

若目标是"像 Codex 那样无缝复用用户 Chrome 登录态"，路线 A 是唯一对标方案，且内核已具备接收端能力，主要成本在扩展 + native host + 授权链路这三块新基建。建议先做路线 B 的最小验证跑通内核侧，再决定要不要投 A。

cc @lizi（浏览器控制内核相关改动请先对齐 `packages/browser-control-runtime/upstream/MAINTAINING.md`）

Start by reading packages/browser-control-runtime's profiles.ts and config-mutations.ts, then review buildOpenClawChromeLaunchArgs and upstream/MAINTAINING.md. Validate the existing external-CDP path and compare the extension/native-host, manual-CDP, and password-manager options. Done means documenting a decided route, constraints, and next implementation scope.

Written by the indexing model from the issue text.