gstack 浏览器架构决策为什么放弃连接真实 Chrome改用 Playwright 打包的 Chromium【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文基于 gstack 的设计记录 CHROME_VS_CHROMIUM_EXPLORATION.md完整还原 gstack 浏览器子系统browse server从“通过 CDP 连接用户真实 Chrome”的原始设想到最终收敛为“Playwright 打包 Chromium 持久化上下文 Side Panel 扩展”这一 headed 架构的决策全过程。读完后你能掌握 gstack 中 headless/headed 两种浏览器状态的实际实现差异、扩展加载的技术前提launchPersistentContext与--load-extension、Side Panel 数据桥接机制以及如何在仓库源码中自行验证这些架构事实。原始设想连接用户的真实 Chromegstack 的$B connect最初的设计目标是接入用户正在使用的真实 Chrome 浏览器——带着用户自己的 cookies、登录会话、扩展和已打开的标签页从此不再需要 cookie 导入流程。原始设计包含三步通过chromium.connectOverCDP(wsUrl)以 CDPChrome DevTools Protocol连接一个正在运行的 Chrome优雅地退出 Chrome再以--remote-debugging-port9222重新启动从而获得用户真实浏览器上下文的访问能力。为支撑这一设想仓库中曾存在chrome-launcher.ts——约 361 行代码负责浏览器二进制发现、CDP 端口探测与运行时检测——方法也因此被命名为connectCDP()环境变量则叫BROWSE_CDP_URL。现实阻碍真实 Chrome 静默拒绝--load-extension设想落地的关键障碍是真实 Chrome 在被 Playwright 以channel: chrome方式启动时会静默忽略--load-extension启动参数扩展根本加载不出来。而 gstack 的 Side Panel侧边栏面板Activity 活动流、ref引用叠加层、Chat 对话完全依赖这个 Chrome 扩展见 extension/ 目录含 manifest.json、background.js 等。扩展加载不出来headed 模式的核心体验就不成立。于是实现上回退到了 Playwright 打包的 Chromium它通过chromium.launchPersistentContext()启动并能可靠地以--load-extension--disable-extensions-except加载扩展。但命名却没有跟着改——connectCDP()、connectionMode: cdp、BROWSE_CDP_URL、chrome-launcher.ts都保留了下来。原始设想访问用户真实浏览器状态实际上从未实现每次启动的都是一个全新浏览器功能上等价于 Playwright Chromium却留下了 361 行死代码和一系列误导性命名。发现五个误导性命名的死代码2026-03-22设计文档记录了一次/office-hours设计会话中对 browse 子系统的架构追溯发现五处命名与实际行为不符的问题connectCDP()并没有使用 CDP——它实际调用的是launchPersistentContext()connectionMode: cdp名不副实——它只代表 “headed 模式”chrome-launcher.ts是死代码——它唯一的导入点位于一个不可达的attemptReconnect()方法内preExistingTabIds是为“保护真实 Chrome 标签页”设计的但我们从不连接真实 Chrome$B handoffheadless → headed 切换当时走的是另一套 APIlaunch()newContext()无法加载扩展由此产生了两种不一致的 “headed 体验”。前四条均可在当前仓库源码中得到印证反向印证这些符号已从代码中消失chrome-launcher.ts已不在 browse/src/ 目录中attemptReconnect、preExistingTabIds在全仓库搜索中已无命中。修复改名、删除、收敛、门控重命名Renamed旧名误导性新名如实描述connectCDP()launchHeaded()connectionMode: cdpconnectionMode: headedBROWSE_CDP_URLBROWSE_HEADED当前源码中可以看到改名后的完整形态browser-manager.ts 里状态字段已收敛为connectionMode: launched | headed不存在cdp取值CLI 启动路径在 cli.ts 中写入BROWSE_HEADED1服务端在 server.ts 读取该变量决定父进程看门狗行为headed 模式下禁用避免守护进程误杀用户可见窗口无 DISPLAY 的 Linux 环境则据此在 xvfb.ts 决定是否拉起 Xvfb。对应的回归测试见 restart-env.test.ts 与 watchdog.test.ts。删除Deletedchrome-launcher.ts361 行死代码attemptReconnect()不可达的死方法preExistingTabIds死概念reconnecting字段死状态cdp-connect.test.ts针对已删除代码的测试。收敛Converged$B handoff现在与$B connect使用同一条启动路径launchPersistentContext() 扩展加载headed 模式从此只有一种不再是两种。Handoff 也因此免费获得了扩展与 Side Panel。这一点在 browser-manager.ts 的handoff()实现中可以逐行核实注释明确写明 “Launch new headed browser with extension (same as launchHeaded)”L1700-L1701与launchHeaded()相同的扩展参数--disable-extensions-except/--load-extensionL1713-L1714相同的 profile 解析resolveChromiumProfile()与单实例锁清理cleanSingletonLocks注释还指出这正是修复过的“第三条启动路径漂移”L1722-L1728相同的反自动化标识剥离ignoreDefaultArgs: STEALTH_IGNORE_DEFAULT_ARGSL1764。handoff 的完整流程采用“先启动、后关闭”的安全回滚顺序保存 headless 状态 → 启动新的 headed 浏览器 → 恢复状态 → 关闭旧 headless 浏览器任一步失败则 headless 浏览器原封不动。BROWSER.md 中对该命令的产品级描述是“Open visible Chrome at current page for user takeover (CAPTCHA, MFA, complex auth)”BROWSER.md。门控Gated设计文档中的原始门控方案侧边栏 Chat 功能置于--chat标志之后$B connect默认仅 Activity feed refs$B connect --chat额外启用实验性的独立 chat agent。需要注意当前仓库的最新状态根据 CHANGELOG.md 的记录侧边栏 agent 后来已经“ungated”——不再要求--chat标志在 headed 模式下始终可用且安全模型与宿主 agent 本身一致Bash、Read、Glob、Grep 作用于 localhost。因此--chat门控属于该设计阶段的中间状态阅读旧文档时需以 CHANGELOG 的后续条目为准。修复后的架构全景设计文档给出的最终架构图如下Browser States: HEADLESS (default) ←→ HEADED ($B connect or $B handoff) Playwright Playwright (same engine) launch() launchPersistentContext() invisible visible extension side panel Sidebar (orthogonal add-on, headed only): Activity tab — always on, shows live browse commands Refs tab — always on, shows ref overlays Chat tab — opt-in via --chat, experimental standalone agent Data Bridge (sidebar → workspace): Sidebar writes to .context/sidebar-inbox/*.json Workspace reads via $B inbox对照当前源码这张图中的每条边都有落点HEADED 状态launchHeaded()于 browser-manager.ts#L537核心是chromium.launchPersistentContext(userDataDir, {...})L674传入headless: false、扩展加载参数、自定义 User-Agent、代理配置与ignoreDefaultArgs。代码注释直接点题L588-L590“Extensions REQUIRE launchPersistentContext (not launch newContext). Real Chrome (executablePath/channel) silently blocks --load-extension, so we use Playwrights bundled Chromium which reliably loads extensions.”HEADLESS 状态launch()路径同文件 L525 附近可见其收尾的applyStealth与newTab使用 Playwright 的launch() 上下文无窗口。Data Bridge$B inbox元命令实现在 meta-commands.ts#L851直接读取 git 仓库根下.context/sidebar-inbox/目录中的 JSON 消息文件支持inbox [--clear]清空命令注册见 commands.ts#L168。侧边栏把 scout 消息写成 JSON 文件工作区 agent 通过 inbox 命令消费——这是一个纯文件系统的异步消息桥不依赖任何额外 IPC。为什么不用真实 Chrome安全策略与替代路径设计文档对 “Why Not Real Chrome” 的解释有两层真实 Chrome 的行为当 Chrome 由 Playwright 启动时--load-extension被静默忽略。这是 Chromium 系浏览器的安全特性——通过命令行参数加载扩展的能力受到限制以防止恶意扩展注入。Playwright 打包 Chromium 的差异它面向测试与自动化场景设计没有这项限制并且通过 Playwright 的ignoreDefaultArgs选项还能进一步剥离 Playwright 自身会附加的、阻碍扩展加载的默认参数。当前仓库在 stealth.ts 中将这部分集中管理STEALTH_IGNORE_DEFAULT_ARGS常量列出要通过ignoreDefaultArgs剥离的 Playwright 默认参数包括扩展加载阻塞项、--enable-automation等自动化特征并 “spread into ignoreDefaultArgs” 被三个启动路径共享保证 headless、headed 与 handoff 的反检测姿态一致。围绕“真实浏览器状态”这一原始目标文档给出的替代路径不是重连真实 Chrome而是Cookie 导入$B cookie-import现已可用实现见 cookie-import-browser.tsConductor 会话注入未来方向——侧边栏向工作区 agent 发送消息。源码纵深headed 启动的完整细节除了文档本身的设计叙述以下几个源码细节解释了 headed 模式在生产环境中的健壮性建议结合阅读扩展路径查找与自定义 Chromium 门控findExtensionPath()browser-manager.ts#L377定位 gstack 扩展目录isCustomChromium()L41判断是否运行在 gbrowser/GStack Browser 这类把扩展“烧录”为组件扩展的自定义 Chromium 构建上——此时跳过--load-extension因为重复加载会触发ServiceWorkerState::SetWorkerIdDCHECK 崩溃L560-L567 注释。可自定义的二进制入口GSTACK_CHROMIUM_PATH环境变量可指向 GStack Browser.app 捆绑的 ChromiumL604-L606这是“不改签名 bundle、只在外层 wrapper 做品牌化”的 #2242 事故后的设计约束——就地重命名签名单元会导致 macOS 上 GPU 进程崩溃代码注释明确警告不得重新引入对该 bundle 的写入L608-L634并有browse/test/rebrand-signed-bundle.test.ts守护。单实例锁自愈Chromium 的ProcessSingleton在存在上次硬崩溃遗留的SingletonLock/Socket/Cookie时会拒绝启动因此launchHeaded()与handoff()都在启动前调用cleanSingletonLocks(userDataDir)L602、L1728。反自动化特征剥离STEALTH_LAUNCH_ARGSblink 级--disable-blink-featuresAutomationControlled等buildGStackLaunchArgs()针对 gbrowser 定制 Chromium 构建的硬件/GPU/UA-CH 覆盖补丁开关对标准 Playwright Chromium 是无操作构成启动参数主体启动后再经applyStealth()做 JS 层的 Layer C 隐身navigator.webdriver掩码、window.chrome.*形状恢复等stealth.ts 注释强调三个启动路径共用同一实现以避免漂移。适用前提与限制本文所述架构与命名以当前仓库状态为准launchHeaded()/handoff()/BROWSE_HEADED等均为修复后的现行符号文档中提到的connectCDP()、chrome-launcher.ts、BROWSE_CDP_URL仅存在于历史记录与设计叙述中。headed 模式依赖 Playwright 打包的 Chromium 或其替代 bundleGSTACK_CHROMIUM_PATHLinux 无显示环境时由 browse server 自动拉起 Xvfbxvfb.tsdistroless 等精简镜像可能还需字体/dbus/gtk 库才能渲染 headed 窗口BROWSER.md。侧边栏 Chat 的门控状态经历过变化--chat门控 → 取消门控引用行为时请以 CHANGELOG.md 对应版本条目为准。该架构决策的根因Chrome 对--load-extension的静默拦截属于上游浏览器行为gstack 侧的约束是headed 模式必须依赖可加载扩展的 Chromium 构建这是 Side Panel 体验的硬前提。小结这篇设计文档的价值在于完整记录了一次“架构诚实化”过程一个从未实现的功能CDP 连接真实 Chrome在代码中留下了方法名、环境变量、361 行启动器与一组守护状态通过一次架构追溯团队将命名修正为与行为一致launchHeaded/headed/BROWSE_HEADED、删除了全部死代码、并把 handoff 与 connect 收敛到同一条launchPersistentContext()扩展加载路径上。对使用 gstack 的开发者而言实际结论是$B connect与$B handoff现在提供同一种 headed 体验——可见窗口、gstack 扩展与 Side PanelActivity/Refs 常驻通过.context/sidebar-inbox/*.json$B inbox完成侧边栏到工作区的数据回传而“访问用户真实会话”的目标走 cookie 导入与会话注入路线而非重连真实 Chrome。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
gstack 浏览器架构决策：为什么放弃连接真实 Chrome，改用 Playwright 打包的 Chromium
gstack 浏览器架构决策为什么放弃连接真实 Chrome改用 Playwright 打包的 Chromium【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文基于 gstack 的设计记录 CHROME_VS_CHROMIUM_EXPLORATION.md完整还原 gstack 浏览器子系统browse server从“通过 CDP 连接用户真实 Chrome”的原始设想到最终收敛为“Playwright 打包 Chromium 持久化上下文 Side Panel 扩展”这一 headed 架构的决策全过程。读完后你能掌握 gstack 中 headless/headed 两种浏览器状态的实际实现差异、扩展加载的技术前提launchPersistentContext与--load-extension、Side Panel 数据桥接机制以及如何在仓库源码中自行验证这些架构事实。原始设想连接用户的真实 Chromegstack 的$B connect最初的设计目标是接入用户正在使用的真实 Chrome 浏览器——带着用户自己的 cookies、登录会话、扩展和已打开的标签页从此不再需要 cookie 导入流程。原始设计包含三步通过chromium.connectOverCDP(wsUrl)以 CDPChrome DevTools Protocol连接一个正在运行的 Chrome优雅地退出 Chrome再以--remote-debugging-port9222重新启动从而获得用户真实浏览器上下文的访问能力。为支撑这一设想仓库中曾存在chrome-launcher.ts——约 361 行代码负责浏览器二进制发现、CDP 端口探测与运行时检测——方法也因此被命名为connectCDP()环境变量则叫BROWSE_CDP_URL。现实阻碍真实 Chrome 静默拒绝--load-extension设想落地的关键障碍是真实 Chrome 在被 Playwright 以channel: chrome方式启动时会静默忽略--load-extension启动参数扩展根本加载不出来。而 gstack 的 Side Panel侧边栏面板Activity 活动流、ref引用叠加层、Chat 对话完全依赖这个 Chrome 扩展见 extension/ 目录含 manifest.json、background.js 等。扩展加载不出来headed 模式的核心体验就不成立。于是实现上回退到了 Playwright 打包的 Chromium它通过chromium.launchPersistentContext()启动并能可靠地以--load-extension--disable-extensions-except加载扩展。但命名却没有跟着改——connectCDP()、connectionMode: cdp、BROWSE_CDP_URL、chrome-launcher.ts都保留了下来。原始设想访问用户真实浏览器状态实际上从未实现每次启动的都是一个全新浏览器功能上等价于 Playwright Chromium却留下了 361 行死代码和一系列误导性命名。发现五个误导性命名的死代码2026-03-22设计文档记录了一次/office-hours设计会话中对 browse 子系统的架构追溯发现五处命名与实际行为不符的问题connectCDP()并没有使用 CDP——它实际调用的是launchPersistentContext()connectionMode: cdp名不副实——它只代表 “headed 模式”chrome-launcher.ts是死代码——它唯一的导入点位于一个不可达的attemptReconnect()方法内preExistingTabIds是为“保护真实 Chrome 标签页”设计的但我们从不连接真实 Chrome$B handoffheadless → headed 切换当时走的是另一套 APIlaunch()newContext()无法加载扩展由此产生了两种不一致的 “headed 体验”。前四条均可在当前仓库源码中得到印证反向印证这些符号已从代码中消失chrome-launcher.ts已不在 browse/src/ 目录中attemptReconnect、preExistingTabIds在全仓库搜索中已无命中。修复改名、删除、收敛、门控重命名Renamed旧名误导性新名如实描述connectCDP()launchHeaded()connectionMode: cdpconnectionMode: headedBROWSE_CDP_URLBROWSE_HEADED当前源码中可以看到改名后的完整形态browser-manager.ts 里状态字段已收敛为connectionMode: launched | headed不存在cdp取值CLI 启动路径在 cli.ts 中写入BROWSE_HEADED1服务端在 server.ts 读取该变量决定父进程看门狗行为headed 模式下禁用避免守护进程误杀用户可见窗口无 DISPLAY 的 Linux 环境则据此在 xvfb.ts 决定是否拉起 Xvfb。对应的回归测试见 restart-env.test.ts 与 watchdog.test.ts。删除Deletedchrome-launcher.ts361 行死代码attemptReconnect()不可达的死方法preExistingTabIds死概念reconnecting字段死状态cdp-connect.test.ts针对已删除代码的测试。收敛Converged$B handoff现在与$B connect使用同一条启动路径launchPersistentContext() 扩展加载headed 模式从此只有一种不再是两种。Handoff 也因此免费获得了扩展与 Side Panel。这一点在 browser-manager.ts 的handoff()实现中可以逐行核实注释明确写明 “Launch new headed browser with extension (same as launchHeaded)”L1700-L1701与launchHeaded()相同的扩展参数--disable-extensions-except/--load-extensionL1713-L1714相同的 profile 解析resolveChromiumProfile()与单实例锁清理cleanSingletonLocks注释还指出这正是修复过的“第三条启动路径漂移”L1722-L1728相同的反自动化标识剥离ignoreDefaultArgs: STEALTH_IGNORE_DEFAULT_ARGSL1764。handoff 的完整流程采用“先启动、后关闭”的安全回滚顺序保存 headless 状态 → 启动新的 headed 浏览器 → 恢复状态 → 关闭旧 headless 浏览器任一步失败则 headless 浏览器原封不动。BROWSER.md 中对该命令的产品级描述是“Open visible Chrome at current page for user takeover (CAPTCHA, MFA, complex auth)”BROWSER.md。门控Gated设计文档中的原始门控方案侧边栏 Chat 功能置于--chat标志之后$B connect默认仅 Activity feed refs$B connect --chat额外启用实验性的独立 chat agent。需要注意当前仓库的最新状态根据 CHANGELOG.md 的记录侧边栏 agent 后来已经“ungated”——不再要求--chat标志在 headed 模式下始终可用且安全模型与宿主 agent 本身一致Bash、Read、Glob、Grep 作用于 localhost。因此--chat门控属于该设计阶段的中间状态阅读旧文档时需以 CHANGELOG 的后续条目为准。修复后的架构全景设计文档给出的最终架构图如下Browser States: HEADLESS (default) ←→ HEADED ($B connect or $B handoff) Playwright Playwright (same engine) launch() launchPersistentContext() invisible visible extension side panel Sidebar (orthogonal add-on, headed only): Activity tab — always on, shows live browse commands Refs tab — always on, shows ref overlays Chat tab — opt-in via --chat, experimental standalone agent Data Bridge (sidebar → workspace): Sidebar writes to .context/sidebar-inbox/*.json Workspace reads via $B inbox对照当前源码这张图中的每条边都有落点HEADED 状态launchHeaded()于 browser-manager.ts#L537核心是chromium.launchPersistentContext(userDataDir, {...})L674传入headless: false、扩展加载参数、自定义 User-Agent、代理配置与ignoreDefaultArgs。代码注释直接点题L588-L590“Extensions REQUIRE launchPersistentContext (not launch newContext). Real Chrome (executablePath/channel) silently blocks --load-extension, so we use Playwrights bundled Chromium which reliably loads extensions.”HEADLESS 状态launch()路径同文件 L525 附近可见其收尾的applyStealth与newTab使用 Playwright 的launch() 上下文无窗口。Data Bridge$B inbox元命令实现在 meta-commands.ts#L851直接读取 git 仓库根下.context/sidebar-inbox/目录中的 JSON 消息文件支持inbox [--clear]清空命令注册见 commands.ts#L168。侧边栏把 scout 消息写成 JSON 文件工作区 agent 通过 inbox 命令消费——这是一个纯文件系统的异步消息桥不依赖任何额外 IPC。为什么不用真实 Chrome安全策略与替代路径设计文档对 “Why Not Real Chrome” 的解释有两层真实 Chrome 的行为当 Chrome 由 Playwright 启动时--load-extension被静默忽略。这是 Chromium 系浏览器的安全特性——通过命令行参数加载扩展的能力受到限制以防止恶意扩展注入。Playwright 打包 Chromium 的差异它面向测试与自动化场景设计没有这项限制并且通过 Playwright 的ignoreDefaultArgs选项还能进一步剥离 Playwright 自身会附加的、阻碍扩展加载的默认参数。当前仓库在 stealth.ts 中将这部分集中管理STEALTH_IGNORE_DEFAULT_ARGS常量列出要通过ignoreDefaultArgs剥离的 Playwright 默认参数包括扩展加载阻塞项、--enable-automation等自动化特征并 “spread into ignoreDefaultArgs” 被三个启动路径共享保证 headless、headed 与 handoff 的反检测姿态一致。围绕“真实浏览器状态”这一原始目标文档给出的替代路径不是重连真实 Chrome而是Cookie 导入$B cookie-import现已可用实现见 cookie-import-browser.tsConductor 会话注入未来方向——侧边栏向工作区 agent 发送消息。源码纵深headed 启动的完整细节除了文档本身的设计叙述以下几个源码细节解释了 headed 模式在生产环境中的健壮性建议结合阅读扩展路径查找与自定义 Chromium 门控findExtensionPath()browser-manager.ts#L377定位 gstack 扩展目录isCustomChromium()L41判断是否运行在 gbrowser/GStack Browser 这类把扩展“烧录”为组件扩展的自定义 Chromium 构建上——此时跳过--load-extension因为重复加载会触发ServiceWorkerState::SetWorkerIdDCHECK 崩溃L560-L567 注释。可自定义的二进制入口GSTACK_CHROMIUM_PATH环境变量可指向 GStack Browser.app 捆绑的 ChromiumL604-L606这是“不改签名 bundle、只在外层 wrapper 做品牌化”的 #2242 事故后的设计约束——就地重命名签名单元会导致 macOS 上 GPU 进程崩溃代码注释明确警告不得重新引入对该 bundle 的写入L608-L634并有browse/test/rebrand-signed-bundle.test.ts守护。单实例锁自愈Chromium 的ProcessSingleton在存在上次硬崩溃遗留的SingletonLock/Socket/Cookie时会拒绝启动因此launchHeaded()与handoff()都在启动前调用cleanSingletonLocks(userDataDir)L602、L1728。反自动化特征剥离STEALTH_LAUNCH_ARGSblink 级--disable-blink-featuresAutomationControlled等buildGStackLaunchArgs()针对 gbrowser 定制 Chromium 构建的硬件/GPU/UA-CH 覆盖补丁开关对标准 Playwright Chromium 是无操作构成启动参数主体启动后再经applyStealth()做 JS 层的 Layer C 隐身navigator.webdriver掩码、window.chrome.*形状恢复等stealth.ts 注释强调三个启动路径共用同一实现以避免漂移。适用前提与限制本文所述架构与命名以当前仓库状态为准launchHeaded()/handoff()/BROWSE_HEADED等均为修复后的现行符号文档中提到的connectCDP()、chrome-launcher.ts、BROWSE_CDP_URL仅存在于历史记录与设计叙述中。headed 模式依赖 Playwright 打包的 Chromium 或其替代 bundleGSTACK_CHROMIUM_PATHLinux 无显示环境时由 browse server 自动拉起 Xvfbxvfb.tsdistroless 等精简镜像可能还需字体/dbus/gtk 库才能渲染 headed 窗口BROWSER.md。侧边栏 Chat 的门控状态经历过变化--chat门控 → 取消门控引用行为时请以 CHANGELOG.md 对应版本条目为准。该架构决策的根因Chrome 对--load-extension的静默拦截属于上游浏览器行为gstack 侧的约束是headed 模式必须依赖可加载扩展的 Chromium 构建这是 Side Panel 体验的硬前提。小结这篇设计文档的价值在于完整记录了一次“架构诚实化”过程一个从未实现的功能CDP 连接真实 Chrome在代码中留下了方法名、环境变量、361 行启动器与一组守护状态通过一次架构追溯团队将命名修正为与行为一致launchHeaded/headed/BROWSE_HEADED、删除了全部死代码、并把 handoff 与 connect 收敛到同一条launchPersistentContext()扩展加载路径上。对使用 gstack 的开发者而言实际结论是$B connect与$B handoff现在提供同一种 headed 体验——可见窗口、gstack 扩展与 Side PanelActivity/Refs 常驻通过.context/sidebar-inbox/*.json$B inbox完成侧边栏到工作区的数据回传而“访问用户真实会话”的目标走 cookie 导入与会话注入路线而非重连真实 Chrome。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
