Browser pane: screenshot/zoom hangs 30s on every page (all other actions work)

Status Open

Maintainer reply None cached

Activity 5 comments · opened Jul 18, 2026

Summary

mcp__Claude_Browser__computer (the in-app "Browser pane") hangs and times out (30s) on every screenshot and zoom action, on every page, while every other action on the same tool (navigate, read_page, get_page_text, clicks, typing) succeeds instantly. Restarting the underlying preview server does not clear it. A different browser-automation tool (Claude in Chrome) captures a screenshot of the identical URL instantly, which rules out a machine/display-level cause.

Environment

Windows 11 (10.0.26200), Claude Code
Browser pane backend: preview_local (in-app preview, not the user's real Chrome)

Repro steps

Open the Browser pane on any URL, e.g.:

``preview_start({ url: "https://example.com" })``

Confirm the page loaded (works fine):

``read_page({ tabId }) -> returns the DOM/accessibility tree correctly get_page_text({ tabId }) -> returns page text correctly``

Attempt a screenshot:

``computer({ tabId, action: "screenshot" })``

Expected: an image of the rendered page.
Actual: times out after 30s with:

computer timed out after 30s. The Browser pane may be stuck (modal dialog, navigation hang, or unresponsive renderer). Check preview_console_logs for errors.

action: "zoom" (region screenshot) fails identically.

What I ruled out before filing

Not page-specific: reproduces on a trivial static page (https://example.com, no JS) as well as on several real-world sites (data.gov.il JSON API responses, a government CMA site with a Kendo/Knockout SPA). read_page succeeds instantly on the exact same loaded page where screenshot hangs — so the issue is isolated to the pixel-capture step, not general rendering/DOM access.
Not stuck/leaked process state: stopped the running preview server (preview_stop) and started a completely fresh one (preview_start) with a new serverId, brand new tab, seconds old. Identical 30s timeout on the very first screenshot attempt.
Not a machine/OS/display issue: the same URL, same machine, same session — captured instantly and correctly via the separate "Claude in Chrome" tool (mcp__claude-in-chrome__computer, driving the real Chrome extension) in the same turn. If this were a GPU/compositor/display-driver problem on the host machine, that capture would fail too; it didn't.
No error in page console: read_console_messages on the loaded page shows nothing relevant.

This combination (only pixel-capture affected; survives a full backend restart; a different capture implementation on the identical page works) points to a bug specific to the Browser pane's own screenshot/zoom capture code path, not the page content, the host environment, or transient process state.

Impact

Any task needing visual verification through the Browser pane (UI screenshots, layout checks, visual confirmation of a rendered page) is currently blocked — read_page/get_page_text-based workflows still work, but nothing that requires an actual image.

View original on GitHub ↗

4 Comments

ZiBibro · 1 month ago

Confirming on a second setup: Windows 11 Pro (10.0.26100), Claude Code 2.1.195, session of 2026-07-19. Browser pane opened via preview_start({url}) on a youtube.com watch page, single tab.

Same signature as described: every computer({action: "screenshot"}) call times out after 30s with the "Browser pane may be stuck" message, while in the same minutes read_page, left_click by ref, javascript_tool (including fetch calls in page context) and wait all succeed on the same tab. Retried screenshot twice, minutes apart — identical timeout both times, with successful clicks/JS in between.

One knock-on detail worth adding to Impact: computer({action: "scroll"}) with coordinate refuses to run without a prior screenshot ("scroll with coordinate requires a prior computer{action:"screenshot"}"), so while screenshot hangs, coordinate-based scrolling is unavailable as well. Ref-based actions (scroll_to, clicks) remain usable. In our session visual keyframe capture had to be replaced with DOM scraping via javascript_tool.

All-The-New · 1 month ago

Confirming this reproduces on macOS too (Claude Desktop), not just Windows —
identical signature: read_page / get_page_text / javascript_tool work instantly
against the tab, but computer{action:"screenshot"} times out at 30s whenever the
Browser pane isn't the focused view, and document.visibilityState stays "hidden".

Impact for agent/automation use: a session driving the Browser pane from the chat
pane can verify DOM and structure, but cannot verify anything paint-gated —
screenshots, and any IntersectionObserver / requestAnimationFrame / scroll-triggered
animation never render. There's no page-level workaround; it needs a human to
manually foreground the pane, which defeats autonomous visual verification.

Requested fix: an offscreen/headless render mode for the Browser pane (composite
frames even when the pane isn't visible), or let screenshot force a one-off
composite of an unfocused pane — so agent sessions can do visual / responsive /
animation checks without a person foregrounding the window.

(Predecessor #53475 was closed NOT_PLANNED; this is the live regression.)

CyberZenithX · 1 month ago

I can confirm this issue still persists on Windows. Claude fails to take a screenshot autonomously and asks the user to do it, or reads the page using JS instead.

Here's a sample Opus output:

thekilteddev · 1 month ago

Confirming again today (2026-07-27), Windows 11 (10.0.26200), Claude Code 2.1.219, MSIX install, RTX 5060 laptop GPU. Same signature: computer{action:"screenshot"} hangs/fails, navigate/javascript_tool/read_console_messages/tabs_* all fine on the same tab.

One data point that might help pin down @All-The-New's foreground/compositing theory: in one session I didn't get the silent 30s hang — I got an immediate (~5s) explicit error instead: "the Browser pane is not displayed, so the page is not compositing frames. Display the pane and retry." That reads like the same root cause (pane not composited when backgrounded) with a faster, clearer failure mode than the classic silent 30s hang — possibly a newer build partially addressing this by failing fast with a message, without fixing the underlying "must be foregrounded to render" constraint.

Workaround that's reliably gotten us real pixels in the meantime, for anyone else stuck: bypass the MCP tool entirely and drive the project's own installed Playwright directly via a Node script (chromium.launch() → page.goto() → page.screenshot({path})), then Read the resulting PNG. Requires the project to already have playwright in node_modules, but it's unaffected by whatever's wedging the MCP capture path.

Showing cached comments. Read the full discussion on GitHub ↗