OpenCLI 浏览器扩展隐私架构深度解析本地 WebSocket 桥接、权限边界与数据留痕【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址: https://gitcode.com/gh_mirrors/ope/OpenCLI导读OpenCLI 通过一款 Chrome 浏览器扩展Browser Bridge Extension打通了命令行工具与你已登录的浏览器会话让 AI Agent 可以复用现有登录态执行网页自动化任务。本文以仓库根目录的 PRIVACY.md 隐私政策为骨架结合 extension/manifest.json、extension/src/background.ts、extension/src/protocol.ts 等源码逐层拆解该扩展的数据流向、权限申请理由、Cookie 访问边界与本地存储机制帮助你在把浏览器控制权交给命令行之前先弄清楚数据到底去了哪里、谁有权读到什么。一、扩展的职责CLI 与 Chrome 之间的本地桥OpenCLI Browser Extension 的定位非常明确它是 OpenCLI 命令行工具与 Chrome 浏览器之间的一座桥。它接收来自本地运行的 daemon 进程的命令通过仅限localhost的 WebSocket并在与日常浏览会话相互隔离的 Chrome 窗口中执行这些命令。这一架构在 PRIVACY.md 中被表述为Users terminal (opencli CLI) ↓ (spawns) Local daemon process (localhost:19825) ↓ (WebSocket, localhost only) Chrome Extension (this extension) ↓ (Chrome APIs) Isolated Chrome automation window从源码看这条链路中的每个环节都有明确实现daemon 进程监听127.0.0.1:19825见 src/daemon.ts 中的httpServer.listen(PORT, 127.0.0.1, ...)扩展侧的连接常量extension/src/protocol.ts 定义了三组端点DAEMON_HOST localhost、DAEMON_PORT 19825DAEMON_WS_URL ws://localhost:19825/extWebSocket 命令通道DAEMON_PING_URL http://localhost:19825/ping轻量健康探测端点扩展在每次建立 WebSocket 前先探测 daemon 是否存活服务工作者extension/src/background.ts 作为 MV3 service worker维护 WebSocket 连接、按命令类型分发到chrome.debugger/chrome.tabs/chrome.cookies等 Chrome API并把结果回传给 daemon。也就是说扩展是 CLI 命令在浏览器侧的执行器而所有命令都来自本机、结果也返回本机没有任何一跳离开localhost。二、数据收集承诺不收集、不存储、不传输、不出售PRIVACY.md 用最高优先级声明了扩展的数据立场扩展不收集、不存储、不传输、不出售任何个人数据。具体拆分为三点无分析、无遥测没有任何数据被发送到远程服务器无用户追踪不创建 cookie、标识符或指纹fingerprint无外部网络请求所有通信严格限定在localhost即 WebSocket 到ws://localhost:19825。这三点在源码层面可以得到印证扩展的 WebSocket 目标地址写死为ws://localhost:19825/extextension/src/protocol.ts服务工作者内部也只存在指向该地址的new WebSocket(...)调用extension/src/background.ts。一个值得注意的实现细节是connect()在发起http://localhost:19825/ping探测时显式传入了credentials: omit见 extension/src/background.ts注释说明这是为了避免浏览器把 localhost 的 cookie jar 附加到请求上——一旦 cookie jar 过大会突破 Node 默认请求头大小限制导致 daemon 返回 431 错误。这个细节反向印证了扩展的克制它甚至刻意避免在健康探测中携带任何 cookie 数据。三、权限模型逐项解析扩展申请的权限在 extension/manifest.json 中声明PRIVACY.md 给出了每项权限的申请理由。下表完整继承原文档并补充源码证据权限为什么需要debugger使用 Chrome DevTools Protocol (CDP) 进行浏览器自动化——在隔离窗口中执行 JavaScript、抓取页面内容、截图。tabs创建并管理隔离的自动化窗口与标签页与用户的日常浏览会话相分离。cookies按域名读取站点专属 cookie使 CLI 命令能够以用户已登录的网站身份完成认证。Cookie从不被写入、修改或对外传输。activeTab识别当前激活的标签页用于上下文感知的命令。alarms通过周期性的 keepalive 检查维持到本地 daemon 的 WebSocket 连接。此外当前仓库的 extension/manifest.json 实际声明的权限还包括storage、tabGroups、downloads以及host_permissions: [all_urls]CSP 为script-src self; object-src self。它们的用途分别是storage扩展在chrome.storage.session中持久化会话级状态下文详述storage.local仅用于保存一个随机的 contextId 标识tabGroups把 OpenCLI 交互式会话的标签页归入名为 OpenCLI Browser 的标签组方便用户识别哪些窗口属于自动化容器extension/src/background.ts 中CONTAINER_TAB_GROUP_TITLE常量downloads向 CLI 暴露下载生命周期事件支撑opencli browser wait download命令等待自动化流程触发的文件下载。扩展只观察下载状态并按用户提供的文件名/URL 模式与超时过滤不修改、不重定向、不持久化浏览器下载历史见 extension/README.md。关于host_permissions: all_urls从 extension/src/cdp.ts 的注释可以了解到一个关键事实chrome.debuggerAPI 本身只需要debugger权限并不依赖host_permissions而 CDP 只能附加到http://、https://、about:blank等可调试页面chrome://与chrome-extension://页面会被显式拒绝isDebuggableUrl()函数。因此通配 host 权限与 CDP 自动化能力并不等价真正决定能控制哪些页面的是debugger权限及其附加时的 URL 校验。四、Cookie 访问按需、按域、只读Cookie 是隐私政策中最敏感的部分PRIVACY.md 给出了三条硬性约束扩展只在 CLI 命令显式请求时读取 cookie只为命令所针对的特定域名读取不会也不能一次性导出全部 cookieCookie 数据只返回给本地 daemon 进程绝不发送到任何外部服务器。这三条约束在handleCookies()的实现中得到了代码级落实extension/src/background.tsasync function handleCookies(cmd: Command): PromiseResult { if (!cmd.domain !cmd.url) { return { id: cmd.id, ok: false, error: Cookie scope required: provide domain or url to avoid dumping all cookies }; } const details: chrome.cookies.GetAllDetails {}; if (cmd.domain) details.domain cmd.domain; if (cmd.url) details.url cmd.url; const cookies await chrome.cookies.getAll(details); const data cookies.map((c) ({ name: c.name, value: c.value, domain: c.domain, path: c.path, secure: c.secure, httpOnly: c.httpOnly, expirationDate: c.expirationDate, })); return { id: cmd.id, ok: true, data }; }注意第一道防线如果命令没有携带domain或url扩展直接返回错误拒绝执行导出全部 cookie这类操作。chrome.cookies.getAll也始终以domain/url过滤后返回且返回结果中httpOnly与secure标志会被原样保留供 CLI 侧判断 cookie 的使用范围。结合协议层定义extension/src/protocol.ts 中Command.domain字段注释为 Cookie domain filter可以确认cookie 的可见范围从协议设计上就被限制在命令指定的域名内。五、数据留在本机连接保活、重连与本地状态既然所有流量都不出本机扩展还需要解决一个工程问题在 Manifest V3 的 service worker 随时可能被浏览器回收的情况下如何稳定地维持与 daemon 的 WebSocket 连接。extension/src/background.ts 给出了完整方案应用层 keepalive每 20 秒发送一次{ type: ping, ts: Date.now() }WS_KEEPALIVE_INTERVAL_MS 20_000。原因在注释中写得很清楚Chrome 116 只有在 WebSocket 有活动时才会延长 service worker 生命周期空闲的 OPEN 连接不计入——没有 keepaliveworker 会悬在 30 秒空闲回收与 30 秒闹钟之间指数退避重连1s → 2s → 4s … 封顶 15s 并附加 0~500ms 抖动RECONNECT_BASE_DELAY_MS 1000、RECONNECT_MAX_DELAY_MS 15000连接成功后重置chrome.alarms负责在 worker 被回收后叫醒它继续重连握手消息WebSocket 建立后扩展发送hello消息携带contextId、扩展版本与兼容范围供 daemon 向 CLI 报告版本不匹配。与隐私最相关的是本地状态的生命周期。扩展把会话级状态放进chrome.storage.session而非chrome.storage.local标签页租约注册表opencli_target_lease_registry_v2与命令日志opencli_command_journal_v1都存放在chrome.storage.sessionstorage.session的语义是随 service worker 重启而保留用于自愈恢复随浏览器退出而清空。这正是结果只在用户机器上短暂存在的体现——见 extension/src/background.ts 与 extension/src/journal.ts 的注释说明命令日志journal还做了容量约束最多保留 64 条记录JOURNAL_MAX_ENTRIES 64单条结果超过 64KB 就不再记录回放JOURNAL_RESULT_MAX_BYTES 64 * 1024以控制本地留痕规模。另一个标识符相关的细节是 contextId扩展在首次运行时用crypto.getRandomValues生成一个 8 位随机标识字母表去掉了易混淆字符0/1/o/l/i存放在chrome.storage.local并通过扩展弹窗extension/popup.html展示给用户用于 CLI 侧的多浏览器 profile 路由。它是一个随机生成、无个人信息含义的本地会话标识且不随请求发往任何远程服务器。六、第三方服务与可审计性PRIVACY.md 明确声明该扩展不集成、不发送数据给、也不从任何第三方服务接收数据。结合前文对 WebSocket 目标地址写死为 localhost、健康探测显式credentials: omit的源码证据这一声明与实现是一致的。同时扩展是完全开源的用户可以自行审计全部代码。当前仓库中的相关入口包括extension/manifest.json权限与配置声明当前仓库中的版本号为 1.0.23extension/src/background.tsWebSocket 连接、命令分发、标签页租约与 Cookie 处理extension/src/cdp.tsCDP 执行、截图、网络抓包与下载等待extension/src/protocol.tsCLI / daemon / 扩展三端共享的协议类型与端点常量extension/src/identity.tstargetId ↔ tabId 映射只涉及页面身份元数据extension/src/journal.ts本地命令日志幂等重试机制extension/README.md各权限用途的补充说明含downloads权限的商店审核措辞建议。配套测试同样值得关注extension/src/background.test.ts 覆盖了连接、命令分发与 Cookie 作用域等行为例如断言 ping 请求不会附加 localhost cookie jar、cookies动作的域过滤逻辑可作为声明即行为的验证材料。七、总结隐私边界的四层保障把 PRIVACY.md 与源码对照阅读可以归纳出 OpenCLI 浏览器扩展隐私设计的四层保障网络边界所有通信写死为localhost的 WebSocket/HTTP无任何远程端点权限边界debugger/tabs/cookies等权限都有明确的、与实现一致的用途说明Cookie 读取强制要求域名作用域数据边界cookie 只读不写、下载历史只观察不持久化本地状态存放在随浏览器退出即清空的storage.session中审计边界扩展全部代码开源在仓库的 extension/ 目录任何对隐私有疑虑的用户都可以直接阅读源码与测试验证上述承诺。这套设计解决的核心矛盾是既要让 Agent 复用你已登录的浏览器身份完成自动化又要确保这个过程中产生的所有数据都不离开你的电脑。理解了桥接架构、权限用途和本地存储的生命周期你就能在启用扩展前对浏览器控制权这一授权做出知情的判断。【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址: https://gitcode.com/gh_mirrors/ope/OpenCLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenCLI 浏览器扩展隐私架构深度解析：本地 WebSocket 桥接、权限边界与数据留痕
OpenCLI 浏览器扩展隐私架构深度解析本地 WebSocket 桥接、权限边界与数据留痕【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址: https://gitcode.com/gh_mirrors/ope/OpenCLI导读OpenCLI 通过一款 Chrome 浏览器扩展Browser Bridge Extension打通了命令行工具与你已登录的浏览器会话让 AI Agent 可以复用现有登录态执行网页自动化任务。本文以仓库根目录的 PRIVACY.md 隐私政策为骨架结合 extension/manifest.json、extension/src/background.ts、extension/src/protocol.ts 等源码逐层拆解该扩展的数据流向、权限申请理由、Cookie 访问边界与本地存储机制帮助你在把浏览器控制权交给命令行之前先弄清楚数据到底去了哪里、谁有权读到什么。一、扩展的职责CLI 与 Chrome 之间的本地桥OpenCLI Browser Extension 的定位非常明确它是 OpenCLI 命令行工具与 Chrome 浏览器之间的一座桥。它接收来自本地运行的 daemon 进程的命令通过仅限localhost的 WebSocket并在与日常浏览会话相互隔离的 Chrome 窗口中执行这些命令。这一架构在 PRIVACY.md 中被表述为Users terminal (opencli CLI) ↓ (spawns) Local daemon process (localhost:19825) ↓ (WebSocket, localhost only) Chrome Extension (this extension) ↓ (Chrome APIs) Isolated Chrome automation window从源码看这条链路中的每个环节都有明确实现daemon 进程监听127.0.0.1:19825见 src/daemon.ts 中的httpServer.listen(PORT, 127.0.0.1, ...)扩展侧的连接常量extension/src/protocol.ts 定义了三组端点DAEMON_HOST localhost、DAEMON_PORT 19825DAEMON_WS_URL ws://localhost:19825/extWebSocket 命令通道DAEMON_PING_URL http://localhost:19825/ping轻量健康探测端点扩展在每次建立 WebSocket 前先探测 daemon 是否存活服务工作者extension/src/background.ts 作为 MV3 service worker维护 WebSocket 连接、按命令类型分发到chrome.debugger/chrome.tabs/chrome.cookies等 Chrome API并把结果回传给 daemon。也就是说扩展是 CLI 命令在浏览器侧的执行器而所有命令都来自本机、结果也返回本机没有任何一跳离开localhost。二、数据收集承诺不收集、不存储、不传输、不出售PRIVACY.md 用最高优先级声明了扩展的数据立场扩展不收集、不存储、不传输、不出售任何个人数据。具体拆分为三点无分析、无遥测没有任何数据被发送到远程服务器无用户追踪不创建 cookie、标识符或指纹fingerprint无外部网络请求所有通信严格限定在localhost即 WebSocket 到ws://localhost:19825。这三点在源码层面可以得到印证扩展的 WebSocket 目标地址写死为ws://localhost:19825/extextension/src/protocol.ts服务工作者内部也只存在指向该地址的new WebSocket(...)调用extension/src/background.ts。一个值得注意的实现细节是connect()在发起http://localhost:19825/ping探测时显式传入了credentials: omit见 extension/src/background.ts注释说明这是为了避免浏览器把 localhost 的 cookie jar 附加到请求上——一旦 cookie jar 过大会突破 Node 默认请求头大小限制导致 daemon 返回 431 错误。这个细节反向印证了扩展的克制它甚至刻意避免在健康探测中携带任何 cookie 数据。三、权限模型逐项解析扩展申请的权限在 extension/manifest.json 中声明PRIVACY.md 给出了每项权限的申请理由。下表完整继承原文档并补充源码证据权限为什么需要debugger使用 Chrome DevTools Protocol (CDP) 进行浏览器自动化——在隔离窗口中执行 JavaScript、抓取页面内容、截图。tabs创建并管理隔离的自动化窗口与标签页与用户的日常浏览会话相分离。cookies按域名读取站点专属 cookie使 CLI 命令能够以用户已登录的网站身份完成认证。Cookie从不被写入、修改或对外传输。activeTab识别当前激活的标签页用于上下文感知的命令。alarms通过周期性的 keepalive 检查维持到本地 daemon 的 WebSocket 连接。此外当前仓库的 extension/manifest.json 实际声明的权限还包括storage、tabGroups、downloads以及host_permissions: [all_urls]CSP 为script-src self; object-src self。它们的用途分别是storage扩展在chrome.storage.session中持久化会话级状态下文详述storage.local仅用于保存一个随机的 contextId 标识tabGroups把 OpenCLI 交互式会话的标签页归入名为 OpenCLI Browser 的标签组方便用户识别哪些窗口属于自动化容器extension/src/background.ts 中CONTAINER_TAB_GROUP_TITLE常量downloads向 CLI 暴露下载生命周期事件支撑opencli browser wait download命令等待自动化流程触发的文件下载。扩展只观察下载状态并按用户提供的文件名/URL 模式与超时过滤不修改、不重定向、不持久化浏览器下载历史见 extension/README.md。关于host_permissions: all_urls从 extension/src/cdp.ts 的注释可以了解到一个关键事实chrome.debuggerAPI 本身只需要debugger权限并不依赖host_permissions而 CDP 只能附加到http://、https://、about:blank等可调试页面chrome://与chrome-extension://页面会被显式拒绝isDebuggableUrl()函数。因此通配 host 权限与 CDP 自动化能力并不等价真正决定能控制哪些页面的是debugger权限及其附加时的 URL 校验。四、Cookie 访问按需、按域、只读Cookie 是隐私政策中最敏感的部分PRIVACY.md 给出了三条硬性约束扩展只在 CLI 命令显式请求时读取 cookie只为命令所针对的特定域名读取不会也不能一次性导出全部 cookieCookie 数据只返回给本地 daemon 进程绝不发送到任何外部服务器。这三条约束在handleCookies()的实现中得到了代码级落实extension/src/background.tsasync function handleCookies(cmd: Command): PromiseResult { if (!cmd.domain !cmd.url) { return { id: cmd.id, ok: false, error: Cookie scope required: provide domain or url to avoid dumping all cookies }; } const details: chrome.cookies.GetAllDetails {}; if (cmd.domain) details.domain cmd.domain; if (cmd.url) details.url cmd.url; const cookies await chrome.cookies.getAll(details); const data cookies.map((c) ({ name: c.name, value: c.value, domain: c.domain, path: c.path, secure: c.secure, httpOnly: c.httpOnly, expirationDate: c.expirationDate, })); return { id: cmd.id, ok: true, data }; }注意第一道防线如果命令没有携带domain或url扩展直接返回错误拒绝执行导出全部 cookie这类操作。chrome.cookies.getAll也始终以domain/url过滤后返回且返回结果中httpOnly与secure标志会被原样保留供 CLI 侧判断 cookie 的使用范围。结合协议层定义extension/src/protocol.ts 中Command.domain字段注释为 Cookie domain filter可以确认cookie 的可见范围从协议设计上就被限制在命令指定的域名内。五、数据留在本机连接保活、重连与本地状态既然所有流量都不出本机扩展还需要解决一个工程问题在 Manifest V3 的 service worker 随时可能被浏览器回收的情况下如何稳定地维持与 daemon 的 WebSocket 连接。extension/src/background.ts 给出了完整方案应用层 keepalive每 20 秒发送一次{ type: ping, ts: Date.now() }WS_KEEPALIVE_INTERVAL_MS 20_000。原因在注释中写得很清楚Chrome 116 只有在 WebSocket 有活动时才会延长 service worker 生命周期空闲的 OPEN 连接不计入——没有 keepaliveworker 会悬在 30 秒空闲回收与 30 秒闹钟之间指数退避重连1s → 2s → 4s … 封顶 15s 并附加 0~500ms 抖动RECONNECT_BASE_DELAY_MS 1000、RECONNECT_MAX_DELAY_MS 15000连接成功后重置chrome.alarms负责在 worker 被回收后叫醒它继续重连握手消息WebSocket 建立后扩展发送hello消息携带contextId、扩展版本与兼容范围供 daemon 向 CLI 报告版本不匹配。与隐私最相关的是本地状态的生命周期。扩展把会话级状态放进chrome.storage.session而非chrome.storage.local标签页租约注册表opencli_target_lease_registry_v2与命令日志opencli_command_journal_v1都存放在chrome.storage.sessionstorage.session的语义是随 service worker 重启而保留用于自愈恢复随浏览器退出而清空。这正是结果只在用户机器上短暂存在的体现——见 extension/src/background.ts 与 extension/src/journal.ts 的注释说明命令日志journal还做了容量约束最多保留 64 条记录JOURNAL_MAX_ENTRIES 64单条结果超过 64KB 就不再记录回放JOURNAL_RESULT_MAX_BYTES 64 * 1024以控制本地留痕规模。另一个标识符相关的细节是 contextId扩展在首次运行时用crypto.getRandomValues生成一个 8 位随机标识字母表去掉了易混淆字符0/1/o/l/i存放在chrome.storage.local并通过扩展弹窗extension/popup.html展示给用户用于 CLI 侧的多浏览器 profile 路由。它是一个随机生成、无个人信息含义的本地会话标识且不随请求发往任何远程服务器。六、第三方服务与可审计性PRIVACY.md 明确声明该扩展不集成、不发送数据给、也不从任何第三方服务接收数据。结合前文对 WebSocket 目标地址写死为 localhost、健康探测显式credentials: omit的源码证据这一声明与实现是一致的。同时扩展是完全开源的用户可以自行审计全部代码。当前仓库中的相关入口包括extension/manifest.json权限与配置声明当前仓库中的版本号为 1.0.23extension/src/background.tsWebSocket 连接、命令分发、标签页租约与 Cookie 处理extension/src/cdp.tsCDP 执行、截图、网络抓包与下载等待extension/src/protocol.tsCLI / daemon / 扩展三端共享的协议类型与端点常量extension/src/identity.tstargetId ↔ tabId 映射只涉及页面身份元数据extension/src/journal.ts本地命令日志幂等重试机制extension/README.md各权限用途的补充说明含downloads权限的商店审核措辞建议。配套测试同样值得关注extension/src/background.test.ts 覆盖了连接、命令分发与 Cookie 作用域等行为例如断言 ping 请求不会附加 localhost cookie jar、cookies动作的域过滤逻辑可作为声明即行为的验证材料。七、总结隐私边界的四层保障把 PRIVACY.md 与源码对照阅读可以归纳出 OpenCLI 浏览器扩展隐私设计的四层保障网络边界所有通信写死为localhost的 WebSocket/HTTP无任何远程端点权限边界debugger/tabs/cookies等权限都有明确的、与实现一致的用途说明Cookie 读取强制要求域名作用域数据边界cookie 只读不写、下载历史只观察不持久化本地状态存放在随浏览器退出即清空的storage.session中审计边界扩展全部代码开源在仓库的 extension/ 目录任何对隐私有疑虑的用户都可以直接阅读源码与测试验证上述承诺。这套设计解决的核心矛盾是既要让 Agent 复用你已登录的浏览器身份完成自动化又要确保这个过程中产生的所有数据都不离开你的电脑。理解了桥接架构、权限用途和本地存储的生命周期你就能在启用扩展前对浏览器控制权这一授权做出知情的判断。【免费下载链接】OpenCLIMake Any Website into CLI Use your logged-in browser by AI agent.项目地址: https://gitcode.com/gh_mirrors/ope/OpenCLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考