[BUG] Browser pane screenshot always times out (30s) when pane is not displayed — visibilityState "hidden", zero compositor frames (2.1.174; re-file of stale-closed #53475)

Summary

computer {action: "screenshot"} on the Browser pane always times out after 30 s in sessions where the pane is not visibly displayed in the desktop app window (unattended/autonomous sessions). The renderer is healthy the whole time — the page is simply never composited, so the capture waits for a pixel frame that is never produced.

This is a re-file of #53475, which contained the same visibilityState: "hidden" diagnosis and was closed as stale/not-planned with an invitation to open a new issue if still relevant. It is still relevant: reproduced on 2.1.174 across four consecutive sessions. Likely the same underlying cause as #46507, #64655, and the timeout half of #36687 (all closed).

Environment

• Claude Code 2.1.174, Windows desktop app
• Windows 11 Pro, OS build 10.0.26200
• Browser pane tools (mcp__Claude_Browser__*), local Django dev server page (plain server-rendered HTML, no heavy JS)
• Session running unattended — the Browser pane is not open/visible on screen while the agent works

Repro

1. In an unattended session, preview_start a dev server (or open any URL) — pane opens, navOk: true.
2. Immediately call computer {action: "screenshot"} on the fresh tab.
3. → computer timed out after 30s. The Browser pane may be stuck (modal dialog, navigation hang, or unresponsive renderer).

Isolation evidence (gathered live in-session)

The failure is not the renderer, the page, or pane age:

| Check | Result |
|---|---|
| Fresh pane + trivial page, immediate screenshot | 30 s timeout |
| javascript_tool, read_page, navigate, form_input, dispatched clicks on the same tab | all answer instantly, correct results |
| document.visibilityState | "hidden" |
| document.hasFocus() | false |
| requestAnimationFrame callback (3 s race) | never fires |

A hidden page is not composited by Chromium, so it produces zero frames; DOM/JS/a11y tools don't need frames and work fine, but screenshot capture blocks on a frame that never arrives and dies at the 30 s tool timeout.

Impact

• Agents cannot capture proof-of-render in unattended sessions at all — every attempt costs a silent 30 s.
• The error text actively misleads ("modal dialog, navigation hang, or unresponsive renderer") — the renderer is fine; the surface is just not being painted. Agents (and users reading transcripts) chase the wrong causes.

Suggested fixes (any would help)

1. Fail fast with an accurate error: check the target's visibilityState before capturing; if "hidden", return immediately with something like "pane is not visible/composited — screenshots require the Browser pane to be displayed" instead of a 30 s hang.
2. Make capture work while hidden: e.g. disable backgroundThrottling on the pane's WebContents (or briefly force the web contents visible / use a capture path that renders off-screen) for the duration of the capture.
3. At minimum, mention the visibility condition in the timeout message so the failure is diagnosable from the transcript.

---

Diagnosis and report drafted by Claude Code itself (AI-assisted), filed at the user's request.