claude-code - 💡(How to fix) Fix [BUG] Claude-in-Chrome: screenshot tool permanently blocked by Next.js streaming SSR (document_idle timeout) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49027Fetched 2026-04-17 08:52:53
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×4closed ×1commented ×1

Root Cause

Next.js 16 streams HTML via React Server Components. Using read_network_requests, the document request itself shows statusCode: pending even though:

  • document.readyState === 'complete'
  • performance.getEntriesByType('navigation')[0].loadEventEnd is set (non-zero)
  • performance.getEntriesByType('resource') shows zero pending resources
  • No WebSocket connections, no pending fetches, no service workers

The extension's document_idle detection appears to check the document request's completion status at the network/CDP level, which never resolves for streaming SSR responses — even after the DOM is fully rendered and the load event has fired.

Fix Action

Workaround

Use javascript_tool and read_page for page verification instead of screenshot. These tools bypass the idle check and work reliably:

javascript_tool: document.querySelectorAll('table tbody tr').length  // works
read_page: filter="interactive"                                      // works
computer: action="screenshot"                                        // times out

Code Example

javascript_tool: document.querySelectorAll('table tbody tr').length  // works
read_page: filter="interactive"                                      // works
computer: action="screenshot"                                        // times out
RAW_BUFFERClick to expand / collapse

Bug Description

The computer tool's screenshot action always fails with "Page still loading (executeScript waited 45000ms for document_idle)" on Next.js 16 applications that use React Server Components (streaming SSR). The page is fully loaded and interactive — all other tools (javascript_tool, read_page, read_network_requests) work correctly on the same page.

Root Cause Analysis

Next.js 16 streams HTML via React Server Components. Using read_network_requests, the document request itself shows statusCode: pending even though:

  • document.readyState === 'complete'
  • performance.getEntriesByType('navigation')[0].loadEventEnd is set (non-zero)
  • performance.getEntriesByType('resource') shows zero pending resources
  • No WebSocket connections, no pending fetches, no service workers

The extension's document_idle detection appears to check the document request's completion status at the network/CDP level, which never resolves for streaming SSR responses — even after the DOM is fully rendered and the load event has fired.

Reproduction Steps

  1. Create any Next.js 16 app with App Router (React Server Components are the default)
  2. Start the app (next dev or next build && next start — both affected)
  3. Navigate to the app with navigate tool
  4. Call computer with action: "screenshot"times out after 45 seconds
  5. Call javascript_tool on the same tab → works immediately, document.readyState === 'complete'

Investigation Trail

HypothesisTestedResult
HMR WebSocket (dev mode)Used next build && next start (production)Same failure
Service Worker (/sw.js)Unregistered via navigator.serviceWorker.getRegistration().unregister()Same failure
Pending resourcesChecked performance.getEntriesByType('resource')0 pending
localhost-specificTried 127.0.0.1 insteadSame failure
Streaming SSR documentChecked read_network_requestsDocument request shows statusCode: pending

Expected Behavior

screenshot should succeed when:

  • document.readyState === 'complete'
  • loadEventEnd > 0 (Navigation Timing API confirms load is complete)
  • All sub-resources are loaded

The idle detection should not rely solely on the document request's network-level completion status, since streaming SSR intentionally keeps the HTTP response open while progressively flushing HTML — but the DOM is complete and interactive well before the stream closes.

Suggested Fix

Consider using loadEventEnd > 0 from the Navigation Timing API as the idle signal, rather than (or in addition to) the network request completion status. This correctly handles streaming SSR while maintaining the safety guarantee that the page is interactive.

Environment

  • Claude Code: latest (CLI)
  • Claude-in-Chrome extension: latest (Chrome Web Store)
  • Chrome: latest stable
  • macOS: Darwin 25.3.0 (Apple Silicon)
  • Next.js: 16.2.2 (App Router, Turbopack)
  • React: 19 (Server Components enabled by default)

Workaround

Use javascript_tool and read_page for page verification instead of screenshot. These tools bypass the idle check and work reliably:

javascript_tool: document.querySelectorAll('table tbody tr').length  // works
read_page: filter="interactive"                                      // works
computer: action="screenshot"                                        // times out

extent analysis

TL;DR

Consider modifying the idle detection logic to use the Navigation Timing API's loadEventEnd instead of relying solely on the document request's network-level completion status.

Guidance

  • Investigate using loadEventEnd > 0 from the Navigation Timing API as an idle signal to correctly handle streaming SSR.
  • Verify that the page is interactive by checking document.readyState === 'complete' and performance.getEntriesByType('navigation')[0].loadEventEnd is set.
  • As a temporary workaround, use javascript_tool and read_page for page verification instead of screenshot, as they bypass the idle check.
  • Review the computer tool's implementation to ensure it can handle streaming SSR responses and update its idle detection logic accordingly.

Example

No code snippet is provided as the issue does not require a specific code change, but rather a modification to the idle detection logic.

Notes

The suggested fix may require updates to the computer tool's implementation to handle streaming SSR responses. Additionally, the workaround using javascript_tool and read_page may not provide the exact same functionality as the screenshot action.

Recommendation

Apply the workaround using javascript_tool and read_page for page verification until the computer tool's idle detection logic is updated to handle streaming SSR responses. This will allow for reliable page verification while the issue is being addressed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Claude-in-Chrome: screenshot tool permanently blocked by Next.js streaming SSR (document_idle timeout) [1 comments, 2 participants]