我们没有去“点掉”那个权限弹窗 —— 而是从源头绕开它：用一份“已登录的 Chrome 配置副本”另开一个浏览器实例，让自动化连它，弹窗就再也不会出现。
在现代 AI 辅助研发中，Claude Code 通过 chrome-devtools (MCP) 控制真实的 Chrome 浏览器 执行测试与任务。
我们希望这条管道可以完全免人工干预地运行，尤其是在持续集成 (CI) 或深夜无人监控时，浏览器控制指令应无阻力直达。
如果你使用传统的 --autoConnect 参数去直接连接当前运行中的 Chrome 窗口：
由于 Chrome 144+ 的安全规则升级，任何时候当脚本发起远程调试 (CDP) 握手时，Chrome 就会强行弹出系统级原生对话框。
你可能会想：“让 Claude 识别弹窗位置，用键鼠脚本去替我点 Allow 不就行了吗？”
答案是：不可能。这是 Anthropic 极其明确的安全隔离壁垒。
出于防范越权恶意操作的原则，AI 执行环境控制桌面浏览器时，只能执行 Read (截图与结构读取) 级别的接口，完全被切断了往浏览器所属的底层注入键鼠事件的链路。同时，任何使用 AppleScript、Shell 触发后台点击的非官方通道，都会被系统沙箱严格屏蔽。
为了进一步应对窃取 Cookie 的安全隐患，Chrome 从 136 版本起增加了一项核心机制：
如果检测到启动路径指向了默认配置文件目录，它会完全忽略 --remote-debugging-port 调试参数，静默关闭端口通讯。
而使用非默认数据目录 --user-data-dir 启动，虽然能够静默打开调试端口，但你会得到一个空白未登录的浏览器窗口。
我们因此面临一个看似无解的死锁：
如何解开这个不可能三角？我们采用的是“种子复制”方案。
chrome-devtools --autoConnect
为了实现无缝管控，我们把该机制拆分为两个核心模块：
--browserUrl 控制浏览器内核并传输数据。
由于我们已经将此方案整合到了 Claude Code 的 SessionStart 钩子中，系统会在会话建立时自动后台冷启动，通常无感。在异常时可用以下指令维护：
reseed。