[BUG] Chrome extension tools fail on apps with persistent WebSocket connections (Blazor Server, SignalR)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Problem:
All claude-in-chrome tools fail on Blazor Server applications with the error:

_"Page still loading (executeScript waited 8000ms for document_idle). The previous action may have triggered navigation — try again in a moment_"
Blazor Server maintains a persistent SignalR/WebSocket connection for its real-time UI update model. This means the Chrome document_idle state is never reached, as the browser always sees an active network connection. The result is that no tools work — screenshots, read_page, computer actions, etc. all fail with the same timeout.

Impact:

• Blazor Server is a widely used framework for internal enterprise apps
• There is no workaround within the extension settings. The only option is manually disconnecting SignalR (Blazor.disconnect() in DevTools), which breaks the app's interactivity
• Manual screenshots defeat the purpose of the integration

What Should Happen?

All Chrome extension tools (screenshot, read_page, computer, etc.) should work on any fully loaded web page, regardless of whether the page maintains persistent WebSocket or SSE connections.

Error Messages/Logs

Page still loading (executeScript waited 8000ms for document_idle). The previous action may have triggered navigation — try again in a moment_

Steps to Reproduce

1. Run any Blazor Server app locally (e.g. dotnet new blazorserver && dotnet run) 2. Start Claude Code with claude --chrome 3. Navigate to the Blazor app URL 4. Any tool call (screenshot, read_page, etc.) fails with the timeout error

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Code version 2.1.77.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Consider an alternative readiness check that doesn't rely solely on document_idle. Options:

• Use document_end or DOMContentLoaded instead, with WebSocket/SSE connections excluded from idle detection
• Add a configurable timeout strategy (e.g. --chrome-idle-timeout or extension setting)
• Add a "force capture" mode that bypasses idle detection entirely
• Allowlist specific connection types (WebSocket, SSE) to be ignored when determining idle state