Browser Bridge 与标签管理/新标签页扩展冲突：自动化标签页会漂移或被劫持到 chrome-extension 页面

[coolxll]

摘要

OpenCLI 的 Browser Bridge 扩展在扩展较多、且浏览器由组织管理的环境里，容易与“标签管理 / 标签分组 / 新标签页接管”类扩展发生冲突，导致自动化标签页或窗口被重新组织、漂移到别的窗口，或者被短暂切到其他扩展自己的 chrome-extension://... 页面，最终让自动化主链路失败。

这会直接影响类似下面这些实际命令：

opencli twitter timeline --limit 1 -f json
opencli linux-do feed --limit 3 -f json

环境

• OpenCLI 扩展版本：1.5.5
• 以 unpacked extension 方式从本地源码目录加载
• 浏览器环境：您的浏览器由所属组织管理
• Browser Bridge 通过本地 daemon 连接

已确认 / 高概率冲突源

1. 已确认冲突源

• Tab Groups Extension
  https://chromewebstore.google.com/detail/tab-groups-extension/nplimhmoanghlebhdiboeellhgmgommi

禁用这个扩展后，窗口漂移（window drift）现象明显减少。

2. 高概率冲突源

• iTab 新标签页 / 空白页替代
  本地观察到的扩展 ID：mhloojimgilafopcmlcikiidgbbnelip

禁用它后，自动化窗口初始 tab 被接管到其他扩展页的情况明显减少，因此它大概率也是冲突源之一。

观察到的问题

1. 自动化标签页漂移到别的窗口

OpenCLI 创建了独立的 automation window，但标签页后续可能被其他扩展重新分组/搬窗，最终跑到用户当前主窗口里，表现为：

• 有时在新开的 automation window 里执行
• 有时又跑到当前浏览器窗口里
• 行为看起来像随机

典型日志包括：

Navigation to https://x.com drifted to another browser window (...)
Navigation to https://linux.do drifted to another browser window (...)

2. 主链路在导航后断掉

goto() 后，OpenCLI 以为自己还在原来的 tab 上继续执行，但实际 tab 已经被其他扩展挪走或被替换，导致后续 exec 落在错误上下文里，主链路直接失败。

3. tab 被别的扩展页劫持

即使禁用了部分高风险扩展，仍然会间歇性出现：

attach failed: Cannot access a chrome-extension:// URL of different extension
Tip: another Chrome extension may be interfering

这说明目标 tab 在某个时刻被切到了“其他扩展自己的 chrome-extension://... 页面”，导致 CDP attach 失败。

4. 由组织管理的浏览器环境会放大问题

当前 Chrome 明确显示：

您的浏览器由所属组织管理

因此除了用户手动安装的扩展外，还需要考虑：

• 组织策略下发的扩展
• 组织策略对标签页 / 新标签页 / 页面接管行为的影响
• 某些用户无法直接识别或彻底停用的扩展组件

为什么这很关键

Browser Bridge 当前实际上依赖了几条在“重度扩展环境”里并不稳定的假设：

• 创建出来的 automation window 会一直保持隔离
• 选中的 tab 会一直留在原来的 window 里
• 导航结束后，目标 tab 仍然是一个可调试的普通网页 tab

在扩展较多、尤其是带有标签整理/新标签页接管/AI 侧栏/自动化能力的浏览器环境里，这几条假设都可能失效。

建议的改进方向

1. 更强的导航后 rebound / rebind 逻辑

如果原 tab 在导航后变成了 chrome-extension://...，建议：

• 继续在 owned window 内搜索与目标 URL 匹配的真实 web tab
• 在失败前更积极地 rebind
• 不要过早把这类情况直接视为 fatal

2. 更稳的 window drift 恢复能力

如果 tab 被重新分组或重新分配到其他 window：

• 尽量把它视为“可恢复状态”而不是立即失败
• 不要过度依赖创建时的固定 windowId

3. 尽量减少对初始空白页 / 内部页的依赖

新建 automation window 时，如果可以，尽量直接用目标 URL 启动，而不是依赖“先起一个空白 tab，再导航过去”的流程，因为这一步最容易被 new-tab override 类扩展接管。

4. 提升诊断信息

建议在 verbose / daemon logs 里增加：

• attach 失败时的真实最终 URL
• 失败 tab 是否发生过 window 迁移
• 如可行，记录拦截到的 chrome-extension://<id>/...

这会让定位冲突扩展快很多。

5. 文档里明确兼容性说明

建议在 Browser Bridge / extension 文档里明确提到下列扩展类别可能冲突：

• 标签分组 / 标签管理 / tab organizer 扩展
• 新标签页 / blank page override 扩展
• AI sidebar / browser copilot / automation agent 扩展
• 由组织管理的浏览器环境

复现说明

实际复现使用的命令：

opencli twitter timeline --limit 1 -f json
opencli linux-do feed --limit 3 -f json

观察到的过程大致是：

• 开启 Tab Groups Extension 时：明显出现 window drift / tab reassignment
• 禁用它后：窗口漂移明显减少
• 再禁用 iTab 后：自动化 tab 被接管到扩展页的情况进一步减少
• 但即使继续禁用多种 AI / 自动化类扩展，仍可能出现 chrome-extension:// attach 失败

这说明：

• Tab Groups Extension 基本可以确认是冲突源之一
• iTab 也大概率是冲突源之一
• 同时在 managed browser 环境里，可能还存在其他扩展或策略组件继续劫持 tab

希望 upstream 考虑

希望 Browser Bridge 在以下场景下进一步增强健壮性：

• tab regrouping / tab reassignment
• new-tab override / blank-page replacement
• 被其他扩展短暂切到 chrome-extension://... 页
• managed browser 环境下的组织策略干扰

[coolxll]

Summary

The OpenCLI Browser Bridge extension can conflict with other Chrome extensions that manage tabs/windows or override new-tab / blank-page behavior.

In a managed Chrome browser environment, this caused Browser Bridge automation tabs to:

1. drift into a different browser window
2. be reassigned or re-grouped unexpectedly
3. end up on another extension's chrome-extension://... page
4. fail CDP attach with:

attach failed: Cannot access a chrome-extension:// URL of different extension

Environment

• OpenCLI extension: 1.5.5
• Loaded as unpacked extension from local source tree
• Chrome environment: managed by organization
• Browser Bridge connected through local daemon

Confirmed / high-probability conflicting extensions

Confirmed conflict source

• Tab Groups Extension
  https://chromewebstore.google.com/detail/tab-groups-extension/nplimhmoanghlebhdiboeellhgmgommi

Disabling this extension significantly reduced window drift behavior.

High-probability conflict source

• iTab New Tab / blank-page replacement
  Extension ID observed locally: mhloojimgilafopcmlcikiidgbbnelip

Disabling this extension reduced cases where automation tabs appeared to be hijacked into extension-owned pages.

Observed symptoms

1. Window drift

Automation sometimes started in a dedicated OpenCLI automation window, but then the tab appeared in the user's current browser window instead.

This broke the session/window ownership assumptions and led to unstable behavior.

Examples observed:

Navigation to https://x.com drifted to another browser window (...)
Navigation to https://linux.do drifted to another browser window (...)

2. Main flow broken after navigation

Commands such as:

opencli twitter timeline --limit 1 -f json
opencli linux-do feed --limit 3 -f json

would fail because the tab used after goto() was no longer the expected web tab.

3. Tab hijacked to another extension page

Even after disabling several suspicious extensions, we still intermittently hit:

attach failed: Cannot access a chrome-extension:// URL of different extension
Tip: another Chrome extension may be interfering

This suggests another extension, or a managed-browser policy / organization-installed component, is still hijacking the target tab into its own extension page.

4. Managed browser environment makes the problem worse

This happened in a browser marked as:

Your browser is managed by your organization

So there may be organization-installed extensions or policies contributing to tab reassignment or interception.

Why this matters

The Browser Bridge currently assumes that:

• the created automation window remains isolated
• the chosen tab stays in the expected window
• after navigation, the active tab remains a debuggable web tab

Those assumptions do not hold in extension-heavy or managed browser environments.

Suggested robustness improvements

1. More resilient tab rebound logic after navigation

   • if the original tab becomes chrome-extension://...
   • search the owned window for a matching final web tab
   • rebind aggressively before failing

2. Stronger protection against window drift

   • treat window reassignment as recoverable where possible
   • avoid assuming windowId remains fixed after creation

3. Better handling of new-tab or blank-page override extensions

   • avoid flows that depend on a blank or internal starter tab
   • prefer creating the automation window directly with the target URL when possible

4. Better diagnostics

   • log the actual final tab URL when attach fails
   • log whether the failing tab moved windows
   • ideally include the intercepted chrome-extension://<id>/... URL in verbose logs

5. Explicit documentation

   • mention incompatibilities with:
     • tab grouping or tab organizer extensions
     • new-tab override extensions
     • AI sidebar or browser automation extensions
     • managed browser environments

Reproduction notes

The issue was reproducible with real commands like:

opencli twitter timeline --limit 1 -f json
opencli linux-do feed --limit 3 -f json

Behavior changed as conflicting extensions were disabled:

• with Tab Groups Extension enabled:
  • clear window drift / tab reassignment
• after disabling it:
  • less drift, but still occasional chrome-extension:// attach failures
• after disabling iTab too:
  • behavior improved further, but attach failures could still occur, likely due to additional extensions or managed-browser policy

Request

Please consider hardening Browser Bridge against:

• tab regrouping or tab reassignment
• new-tab override behavior
• transient chrome-extension://... interception by other extensions
• managed-browser environments with organization-installed extensions or policies

[Astro-Han]

Thanks, this issue looks valid based on the current Browser Bridge code path.

After reading the extension flow, I think the first failure layer is in the Browser Bridge extension session/tab model rather than in individual adapters like twitter or linux-do.

What the code already does well:

• caches the returned tabId after navigate()
• rejects non-debuggable URLs such as chrome-extension://...
• retries some transient attach / reconnect failures

Where it still seems too fragile:

• handleNavigate() still assumes the original tabId remains the correct target after navigation
• resolveTabId() still treats windowId as a strong ownership boundary for normal automation workspaces
• if a tab is regrouped, moved to another window, or briefly replaced by another extension page, the flow usually falls back to the old automation window instead of rebinding to the surviving real web tab

So the issue is not only the final attach failed error itself. The larger problem is that tab/window drift is treated as fatal too early.

Suggested hardening order:

1. Add post-navigation reconcile / rebind logic in handleNavigate()
   • if the original tab no longer points to a debuggable web URL
   • search for a matching surviving web tab before failing
2. Treat window drift as recoverable where possible
   • if the target tab moved windows but is still the correct page, update session binding instead of rejecting it immediately
3. Improve diagnostics
   • log final tab URL
   • log old/new windowId
   • log whether the tab became chrome-extension://...
4. Add regression tests for:
   • tab moved to another window
   • tab replaced by chrome-extension://...
   • navigation finishing on a different surviving web tab

One more observation: there is already some cross-window rebinding logic for NotebookLM-style workspaces, which suggests the project has already moved in this direction. The missing piece is making that resilience more general for normal automation sessions.

I would treat this as an extension robustness bug rather than adapter-specific behavior.