[BUG] The browser pane `computer { action: "screenshot" }` tool consistently times out after 30s with:

I hit the same failure on Windows 11 (Claude Code 2.1.199, desktop app) and was able to pin down the root cause from inside the affected page.

Root cause

The captures hang whenever the Browser pane is not visible on screen (panel collapsed, covered, or app minimized). Chromium applies occlusion/background throttling to hidden pages: the compositor stops producing frames entirely, and the capture path waits for a compositor frame that will never arrive, until the 30 s MCP timeout fires. DOM tools (read_page, get_page_text, javascript_tool) keep working because they don't need compositor frames — which is why the renderer looks healthy in every other respect.

Evidence, gathered via javascript_tool on the exact tab where screenshot and zoom were both timing out:

{
  "visibilityState": "hidden",
  "hidden": true,
  "hasFocus": true,
  "rafStatus": "requestAnimationFrame never fired (3s timeout)",
  "devicePixelRatio": 1
}

• document.visibilityState === "hidden" → the pane's WebContents is occluded/backgrounded.
• requestAnimationFrame never fires → zero compositor frames are being produced.
• JS still executes fine → the renderer main thread is not stuck (the "modal dialog / navigation hang / unresponsive renderer" wording in the timeout message is a red herring).

The failure is fully deterministic: pane hidden ⇒ 100 % of screenshot/zoom calls time out; pane visible ⇒ captures work.

Suggested fixes

1. Fast-fail with an accurate message: before capturing, evaluate document.visibilityState (or check occlusion state) on the target. If hidden, return immediately with something like "Browser pane is hidden; make it visible to capture, or use read_page instead" rather than a 30 s generic timeout.
2. Make capture work while hidden: disable occlusion throttling on the pane's WebContents (Electron webPreferences.backgroundThrottling: false, and/or Page.setWebLifecycleState("active") for the duration of the capture) so captureScreenshot gets a frame even off-screen.
3. At minimum, add the hidden-pane cause to the timeout message — it is likely the most common trigger, and agents currently retry several times and misdiagnose the renderer as crashed, losing minutes per verification step.

Quick workaround for anyone hitting this: keep the Browser pane visible while asking for screenshots, or probe first with javascript_tool: await Promise.race([new Promise(r=>requestAnimationFrame(()=>r('visible'))), new Promise(r=>setTimeout(()=>r('hidden'),1500))]) — if it returns hidden, don't bother attempting a capture.

i am having the exact same issue

same issue, Claude gave me this for a bug report:
Title: In-app Browser preview never displays; screenshots always fail (Windows desktop app)

Environment

App: Claude/1.20186.1 (MSIX package), Electron 42.5.1, Chromium 148.0.7778.271
OS: Windows 11 Pro (build 10.0.26200), x64
GPU: NVIDIA GeForce RTX 5090
Summary
The in-app Browser/preview pane is never displayed in the app window, and every screenshot capture fails as a result. Reproduces on every session, persists across full OS reboots and app reinstalls (Squirrel → MSIX, both 1.20186.1).

Steps to reproduce

Open a Browser preview in a session.
Observe: no browser panel appears in the app window (logs show [Preview] Created browser preview succeeded).
Attempt a screenshot of the preview.
Expected: the preview panel renders and the screenshot returns an image.
Actual: no panel is visible; screenshot times out (~30s) or fails immediately.

Diagnostic evidence

The preview webContents reports screen 0×0 and window.outerWidth/Height 0×0 even when its tab is active (document.visibilityState stays hidden) — it's mounted off-screen / zero-size, so the compositor never paints a frame.
Screenshot path fails in %APPDATA%\Claude\logs\main.log:
[CDPTools] CDP compressed screenshot failed
[Preview] capturePreviewScreenshot failed: Error: target closed while handling command (stack via destroyPreview → teardownSession, app-1.20186.1)
Not a GPU issue: WebGL initializes fine (ANGLE / NVIDIA RTX 5090 / Direct3D11) and 2D canvas rasterizes correctly.
Not corrupt window state: window-state.json is clean ({"width":1200,"height":800}, no off-screen coordinates).
DOM / JS / console / network tools all work — only frame painting and capture are broken.

Independent reproduction, with main-process log evidence supporting the hidden-pane mechanism.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop, Microsoft Store (MSIX) build — currently 1.21459.0.0; logs show the identical failure on every version back to 1.14271 (first occurrence 2026-06-22)
• NVIDIA discrete GPU (iGPU disabled in BIOS)

Deterministic repro, both directions

• Browser pane hidden ⇒ 100% of computer {action: "screenshot"} and zoom calls time out at 30s. Dozens of attempts across multiple sessions, zero successes.
• Pane made visible ⇒ the very next screenshot succeeded instantly, as did zoom. No other change.
• Throughout, navigate, read_page, read_console_messages, and click/type actions work normally against the same tab, so the CDP session itself is healthy.

Log signature (%APPDATA%\Claude\logs\main.log; for the Store build the real path is AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs)

Each hung capture logs only:

[warn] [Preview MCP] computer timed out after 30000ms

The underlying CDP Page.captureScreenshot commands never resolve — they stay pending until the preview is torn down, at which point they all flush at once:

[error] [CDPTools] CDP compressed screenshot failed {
  error: Error: target closed while handling command
      at O8.detach (...app.asar\.vite\build\index.chunk-....js:...)
      ...
      at Edr.stopAll (...)

(a dozen of these with the same timestamp, one per earlier hung attempt, emitted at pane/preview close).

This is consistent with Chromium not compositing frames for a hidden/occluded webview: Page.captureScreenshot waits for a frame that never comes, and the tool layer gives the generic "renderer may be stuck" timeout.

Ruled out (no effect on the hang; pane visibility was the only variable that mattered):

• Deleting all Chromium caches in the profile (Cache, Code Cache, GPUCache, DawnGraphiteCache, DawnWebGPUCache)
• Updating the app (1.20186.9.0 → 1.21459.0.0)
• Updating NVIDIA drivers
• App restarts

Workaround confirmed: keep the Browser pane visible while captures run.

Two suggestions from the debugging experience: the 30s timeout message ("The Browser pane may be stuck...") is misleading for this case — detecting a hidden pane and either forcing offscreen frame generation (e.g. fromSurface/captureBeyondViewport-style capture or briefly waking the compositor) or returning a "pane not visible" error immediately would save a lot of misdirected debugging.

The root cause of this 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.

This is different from:
https://github.com/anthropics/claude-code/issues/77670
Where the user is describing the preview panel as being open, but the screenshot is failing regardless of what site is loaded in the preview.

Please reopen this issue @codebytere-ant