[BUG] Claude in Chrome: unbounded permission-prompt waits, 10 s post-drop reconnect window, dialogs reported as frozen renderer, subagent tab collisions

Summary

I analysed two months of local logs and transcripts on one Mac (7,227 Claude in Chrome tool calls from Claude Code sessions, Aug 12 – Oct 10, 2026), plus controlled reproductions. 4.7% of calls failed. Only 11 were explicit connection losses, but several other failure classes look like "disconnected" or "frozen" to the agent, and the agent then abandons the task. Six issues follow, most severe first, each with evidence and a suggested fix.

Environment: macOS 27.0 (arm64), Chrome 155.0.8059.40, Claude in Chrome extension 1.0.100, Claude desktop 2.31226.1, Code tab (Claude Code 2.1.295), cloud bridge transport.

1. A pending permission prompt suspends the tool-call timeout with no upper bound

A Chrome call can trigger a site-permission prompt in a session that asks (seen in accept-edits sessions). While the prompt is open, the call's timeout is paused. If nobody answers, the call stays pending until something else ends it — in practice the next bridge WebSocket drop. The agent then gets Bridge connection closed mid-call and reports a disconnect instead of "waiting for permission".

Evidence: three navigate calls waited 22 minutes, 5 hours and 11.3 hours. In each case the desktop log shows Emitted tool permission request … for browser:navigate. Hours later, in the same second, it shows Bridge connection closed (code: 1006 …), Error calling tool: Bridge connection closed mid-call and Permission request … aborted.

Suggested fix: cap the wait (5–10 minutes) and return a distinct, actionable result, such as "permission prompt unanswered", so unattended agents can move on and report it.

2. After a bridge drop, the desktop waits about 10 s for the extension, which sometimes needs longer

When the bridge WebSocket closes, the desktop reconnects within about 2 s. If the extension hasn't re-registered within about 10 s, calls fail with No Chrome extension connected after discovery, shown to the agent as "Claude in Chrome is not connected".

Example:

• 14:57:44: desktop socket closes (code 1006, after 3.3 h).
• 14:57:50: No extensions connected, waiting up to 10000ms for peer_connected.
• 14:58:00 and 14:58:03: tool calls fail.
• 14:58:31: the extension reconnects.

Over two months: 202 established bridge connections closed abnormally, nearly all with code 1006. Those connections had a median lifetime of 37 minutes, and 186 of the closes were not near sleep/wake or a missed pong. The extension usually reconnects within a few seconds (median gap about 3 s), so most drops are harmless. The failures come from the tail: calls in flight are lost, as are calls sent before a slow extension returns.

Suggested fix: hold calls, or keep retrying discovery, for longer than the extension's own stale-socket detection (a 90 s pong timeout checked every 30 s) before failing. Alternatively, return "transient, retry in N s". Related: #99024, #96540.

3. alert()/confirm() still block the tab and are reported as a frozen renderer (1.0.100)

This has the same root cause as #81137: Page.handleJavaScriptDialog is wired only for beforeunload. It still reproduces on 1.0.100. The focus-emulation half of that issue is now fixed.

Repro: on https://example.org, run javascript_tool with setTimeout(() => alert('x'), 300). Then, on the same tab:

• javascript_tool gives Failed to execute JavaScript: CDP sendCommand "Runtime.evaluate" timed out after 45000ms on tab N. The renderer may be frozen or unresponsive.
• computer screenshot gives Script injection timed out after 5000ms — the page is busy or mid-navigation…
• get_page_text gives Page still loading (executeScript waited 45000ms for document_idle)…

Other tabs are unaffected. Navigating the tab to a different URL clears the dialog, with two rough edges:

• Reloading the same URL hangs again when the page alerts on load.
• Navigating away from a tab with an open dialog sometimes returns The "navigate" tool did not respond in time after 60 s, although tabs_context_mcp shows the navigation succeeded.

In two months of real use, 17 failures fell into this 45-second class. That class also includes scripts that genuinely run too long, so not all 17 were dialogs. But none of the messages mentions a dialog, so an agent has no way to tell the two apart.

Suggested fix: handle Page.javascriptDialogOpening for alert, confirm and prompt. At minimum, return "A JavaScript dialog is open on this tab: '<message>'" immediately instead of after 45 s. Optionally auto-dismiss alert, with confirm gated by policy. Related misleading-timeout reports: #96797, #93348.

4. Subagents share one tab group, and navigate without tabId drives the group's first tab

Subagents share the parent session's tab group and can see and act on each other's tabs. navigate without tabId, which its description allows, navigates "the first tab in the session's group". So parallel subagents that omit tabId all drive the same tab.

Evidence: a 23-agent workflow run (CLI 2.1.278) had up to 8 agents operating on one tab. The results were 9 × Couldn't determine which page this action targets, invalidated refs, Inspected target navigated or closed, and Tab N is not in Claude's tab group once another agent's actions removed the group. When each agent created its own tab with tabs_create_mcp and passed tabId, 4 concurrent agents made about 100 calls with zero connection errors.

Suggested fix: scope tabs per agent. Alternatively, require tabId, or return an error instead of silently picking the first tab, when more than one agent is active in the session. Related: #89335, #96538.

(Workaround we now use: a PreToolUse hook on mcp__claude-in-chrome__navigate that denies calls without tabId.)

5. get_page_text returns a fragment on multi-article pages, and nothing on the PDF viewer

• On https://github.com/trending, get_page_text returned a single repository (one <article>), and an agent reported the wrong #1. On pages with several <article> elements it should return all of them, or say that only one was returned.
• On Chrome's PDF viewer (for example https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf) it returns No text content found. Page may contain only images, videos, or canvas-based content., although a screenshot works. 43 historical failures fall in this "no text" class: PDFs, canvas, and SPAs that hadn't rendered yet.

6. Smaller items

• Parallel calls run sequentially. Chrome calls issued in parallel by one agent run one after another: five parallel 40 s javascript_tool polls finished at 45, 85, 125, 165 and 205 s. That may be intended, but it isn't documented, and agents assume a parallel wait happens before a read.
• Auto-connecting to another computer's browser (from reading the code, not observed). In the desktop's browser-selection logic, when the last-paired browser is offline and exactly one other browser on the account is connected, the code appears to auto-connect to it, even when it's on another computer, with only a log warning. In our logs selection always fell back to the paired browser, so this is a code reading, not an observed incident. For unattended sessions it would risk acting in the wrong browser, for example a work laptop's Chrome. Consider requiring confirmation for a non-local browser in that path.
• Multi-browser prompt blocks subagents. "Multiple Chrome browsers are connected … you MUST call AskUserQuestion" can't be answered by a subagent. It blocks unattended runs even when the paired browser is only briefly offline. Consider waiting briefly for the paired device before asking.

---

I collected and analysed this with Claude Code from local logs and transcripts. No personal data is included. I can share redacted log excerpts on request.