[BUG] Browser automation screenshot action times out on all sites (Script injection timeout / document_idle wait)

Status Open
Maintainer reply None cached
Activity 4 comments · opened Jul 15, 2026

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?

Environment:

OS: Windows 11 Pro (10.0.26100)
Client: Claude Code (desktop app)
Affected tools: Browser pane (computer action, screenshot/zoom) and Claude in Chrome extension (computer action, screenshot)
Description:
The screenshot action (and zoom) on both the built-in Browser pane and the Claude in Chrome extension consistently times out, even though page navigation and DOM reads succeed.

What Should Happen?

Errors observed:

Browser pane: computer timed out after 30s. The Browser pane may be stuck (modal dialog, navigation hang, or unresponsive renderer).
Claude in Chrome: Error capturing screenshot: Script injection timed out after 5000ms — the page is busy or mid-navigation...
Claude in Chrome read_page: Failed to read page: Page still loading (executeScript waited 45000ms for document_idle).

Error Messages/Logs

Steps to Reproduce

Reproduction steps:

Start any local static server (e.g. python -m http.server 8791) serving a simple static HTML site.
Navigate the Browser pane or Claude in Chrome tab to http://localhost:8791/index.html. Page loads fully (title updates, all network requests return 200/304).
Call the screenshot action on that tab → times out.
Isolation test: navigate to https://example.com (unrelated external site, no local server involved) → screenshot still times out identically.
Confirmed extension is enabled, has tab permissions, and no pending permission dialogs are blocking the tab.
Fully restarted the Claude Code desktop app and retried → identical failure persists.
Expected behavior: screenshot/zoom returns an image of the rendered page.

Actual behavior: Times out on every site tested (both local and external), on both browser automation surfaces, before and after a full app restart.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.20186.9 (69f150) 2026-07-14T05:52:31.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] · 1 month ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/76649
  2. https://github.com/anthropics/claude-code/issues/74548
  3. https://github.com/anthropics/claude-code/issues/74523

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

ricardopv1 · 1 month ago

Commenting to prevent auto-closure, this seems to be different than the suggested duplicates.

AdamRealE · 1 month ago

This is different from:
https://github.com/anthropics/claude-code/issues/76649

The root cause of the one I linked is that claude desktop can't open the preview tab on it's own, in my environment, and it needs to be open for the screenshot to work. If I've manually opened the preview, screenshots work. When I first installed it, the agent was able to open the preview panel.

olarcher · 1 month ago

Reproducing this on macOS, so it isn't Windows-specific.

Environment: macOS 26.5.2 · Chrome 150.0.7871.115 · Claude in Chrome 1.0.81 · Claude Code 2.1.220

Same split as the report: computer:screenshotScript injection timed out after 5000ms; find / get_page_text / read_pageexecuteScript waited 45000ms for document_idle. Meanwhile navigate, tabs_context_mcp, read_network_requests and read_console_messages all work.

The detail I haven't seen mentioned anywhere: javascript_tool keeps working. On the same tab, in the same second screenshot times out, I can run arbitrary JS in the MAIN world — DOM reads and writes, eval, await fetch, appending elements. So chrome.scripting.executeScript itself is healthy; only the path that injects a content script and waits for document_idle is wedged.

Measured via javascript_tool while screenshot was failing on plain https://example.com:

document.readyState      // "complete"
document.visibilityState // "visible"
requestAnimationFrame    // fires normally
// main thread idle, no long-running script

Ruled out:

  • Page CSP — fails on example.com, which has none.
  • "Page is busy or mid-navigation" (what the error claims) — page is fully idle, per above.
  • Tab visibility — my MCP tab initially was a background tab (visibilityState: "hidden", rAF never firing). Foregrounding it gave visible + rAF firing, and screenshot still timed out. Separate from #78533 / #77679.
  • Streaming SSR — fails on a static page, so distinct from #49027, which explicitly worked on example.com.
  • Extension state — disable/re-enable in chrome://extensions, plus a fresh tab group: no change.

Workaround: anything you'd want a screenshot for can go through javascript_tool instead (read text, query the DOM, click via .click()), which bypasses the document_idle gate entirely.