Claude in Chrome: extension permanently disconnects after screenshot/scroll operations

[salacoste]

Description

The Claude in Chrome browser extension frequently loses its connection during screenshot and scroll operations, entering an unrecoverable state that requires a full Chrome restart.

Environment

• OS: macOS (Darwin 25.1.0, Apple Silicon)
• Chrome: Latest stable
• Claude Code: Latest (installed via Homebrew)
• Node: v25.6.1 (native host runtime)

Steps to Reproduce

1. Start a browser automation session via tabs_context_mcp
2. Navigate to a page (navigate tool) — works fine
3. Take a screenshot (computer tool, action: screenshot) — usually works
4. Scroll the page (computer tool, action: scroll)
5. Take another screenshot immediately after

Result: "Browser extension is not connected" or "Error capturing screenshot: Detached while handling command."

The extension then enters an infinite exponential backoff reconnection loop (100+ attempts over ~2.5 hours) and never recovers. Only a full Chrome restart resolves the issue.

Log Evidence

From ~/.claude/logs/:

1. Timeout triggers the disconnect

[WARN] [Claude in Chrome] Tool call timeout: computer (1c991a7a) after 120000ms, pending calls: 0

2. Delayed response arrives to dead context

[DEBUG] [Claude in Chrome] Bridge received: {"type":"tool_result","tool_use_id":"1c991a7a-...","content":"Error capturing screenshot: Detached while handling command.","is_error":true}
[Claude in Chrome] Received tool_result for unknown call: 1c991a7a

3. Infinite reconnection loop (never recovers)

[INFO] [Claude in Chrome] Bridge reconnecting in 2000ms (attempt 1)
[INFO] [Claude in Chrome] Bridge reconnecting in 15188ms (attempt 6)
...
[INFO] [Claude in Chrome] Bridge reconnecting in 30000ms (attempt 100)

Operation Timing Analysis

Operation	Avg Time	Reliability
tabs_context_mcp	~50ms	Always works
navigate	~350ms	Always works
1st screenshot	~2-5s	Usually works
scroll + screenshot	~20s+	Frequently disconnects

Root Cause Analysis

1. CDP connection fragility: The Chromium DevTools Protocol connection drops during slow operations (screenshots are ~20s)
2. No graceful recovery: Once the CDP session detaches, there is no mechanism to re-establish it
3. Orphaned tool calls: Timed-out calls leave no cleanup, and late responses arrive to dead contexts
4. Exponential backoff never succeeds: The reconnection strategy maxes out at 30s intervals but never actually reconnects — only a Chrome restart works

Configuration

• ~/.claude/.mcp.json has empty mcpServers: {} — no timeout or keepalive settings available
• Native host script (~/.claude/chrome/chrome-native-host) is a simple exec node wrapper with no error handling

Suggested Improvements

1. CDP session recovery: Detect CDP detachment and re-establish the debugging session without requiring Chrome restart
2. Reconnection cap: After N failed attempts, surface a clear error to the user instead of silent infinite retry
3. Operation-specific timeouts: Screenshots need longer timeouts than navigation; consider per-operation timeout configuration
4. Keepalive mechanism: Periodic health check pings on the CDP connection to detect disconnects early
5. Serialized screenshot queue: Prevent overlapping screenshot operations that can race-condition the CDP session

[github-actions]

Found 3 possible duplicate issues:

1. Chrome MCP: Debugger detaches on complex pages, breaking screenshot/coordinate actions #25518
2. Chrome MCP: Extension doesn't reconnect after native messaging host disconnect #24217
3. [BUG] Claude in Chrome MCP extension disconnects during screenshot/JavaScript operations #15743

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[yashasvigirdhar]

happens all the time for me as well

[nocilis]

Claude 1.1.4328 (d8e391) is still having this issue for me

[saka01]

Claude extension is unusable due to this issue.

[Nubaeon]

Root Cause Analysis — Extension Code Level

I've been hitting this daily during browser automation work and dug into the installed extension code (~/.config/google-chrome/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn/1.0.59_0/). There are three compounding bugs that create the unrecoverable state.

Bug 1: Missing chrome.debugger.onDetach listener (primary cause)

The extension registers chrome.debugger.onEvent for console/network tracking but never registers chrome.debugger.onDetach. I searched all extension JS — zero references to onDetach.

When Chrome detaches the debugger mid-operation (due to page navigation, iframe changes, resource pressure, or internal CDP session management), the extension has no way to know. The next sendCommand call fails with "Detached while handling command", which is a different error string than what the retry logic handles (see Bug 2).

Fix: Add an onDetach listener in the CDP wrapper class constructor (where initializeDebuggerEventListener is already called):

chrome.debugger.onDetach.addListener((source, reason) => {
  const tabId = source.tabId;
  // Mark debugger as detached for this tab
  // Reject any pending sendCommand promises
  // Clean up CDP session tracking state
});

Bug 2: sendCommand retry gap

The current sendCommand has a single retry that handles "debugger is not attached" (pre-command state check) — it calls attachDebugger(tabId) and retries once. But the screenshot failure produces "Detached while handling command" (mid-command failure), which is a different error string that falls through to the unhandled error path.

Fix: Extend the catch to handle both error patterns:

const msg = error.message.toLowerCase();
if (msg.includes("not attached") || msg.includes("detached")) {
  await this.attachDebugger(tabId);
  continue; // retry
}

Bug 3: Native messaging port has zero reconnection logic

The service worker's port.onDisconnect handler (line ~99 in the service worker entry) sets port = null, connected = false, and calls a cleanup function. That's it — no reconnection attempt. Compare with the WebSocket bridge path which at least has exponential backoff reconnection (the Xe function).

This means once the native messaging port drops (which happens when the error from Bug 1+2 propagates up), the connection is permanently dead. The bridge reconnection loop you see in logs is the WebSocket path trying (and failing) because auth/pairing state was lost.

Fix: Add reconnection in onDisconnect:

port.onDisconnect.addListener(() => {
  const error = chrome.runtime.lastError?.message;
  port = null; connected = false;
  
  if (error?.includes("native messaging host not found")) return; // no point retrying
  
  // Exponential backoff reconnection
  const delay = Math.min(3000 * Math.pow(2, reconnectAttempt), 60000);
  reconnectAttempt++;
  setTimeout(() => connectToNativeHost(), delay);
});

(Issue #24217 independently identified this same missing reconnection.)

The full cascade

1. Page.captureScreenshot on a complex page takes 20s+
2. Chrome detaches the debugger mid-operation (no onDetach listener catches this)
3. CDP response arrives with "Detached while handling command"
4. sendCommand retry doesn't match this error string → unhandled
5. Error propagates, native messaging port gets confused about state
6. Port disconnects → onDisconnect fires → state cleared → no reconnection
7. All subsequent tool calls fail with "Browser extension is not connected"
8. Only the WebSocket bridge attempts reconnection, but enters infinite backoff because pairing state was lost

Environment

• Chrome: 133 (Linux)
• Claude Code: 2.1.74
• Extension: 1.0.59
• Confirmed on both native messaging and WebSocket bridge paths

Impact

Non-screenshot tools (navigate, javascript_tool, read_page, find, form_input) all work reliably because they use content scripts, not the debugger API. The bug is specific to CDP-based operations (screenshot, scroll).

The fix is ~30 lines across 3 locations in the extension code. Happy to submit a PR if the extension source is opened.