Browser pane fails to composite frames (Viewport 0x0) — read_page/screenshot broken, get_page_text still works

Summary

Reference: PBC #2385-3921-0706 (internal ticket already opened for this issue).

The Claude Browser pane tools fail to render/composite visual frames, while navigation and plain-text extraction still work. This breaks any workflow that depends on read_page, computer (click/screenshot/type), or visual verification, even though the underlying page load succeeds.

Steps to reproduce

1. preview_start with a URL (e.g. https://www.stj.jus.br) — returns navOk: true.
2. read_page with filter: "interactive" — returns (empty page) and Viewport: 0x0.
3. computer with action: "screenshot" — fails with:

Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not compositing frames. Display the pane and retry.

1. get_page_text on the same tab — works normally, returns real extracted page text.

Observed behavior

• Navigation: OK (navOk: true).
• Text extraction (get_page_text): OK.
• Accessibility tree (read_page): broken — empty result, 0x0 viewport.
• Visual capture (computer screenshot): broken — explicit error that the pane "is not displayed" / "not compositing frames".

Expected behavior

read_page and computer screenshot should work whenever preview_start/navigation succeeds and get_page_text can already extract real content from the same tab — the pane should be composited/displayed consistently across all these tools.

Impact

Any task requiring visual page reading, clicking, form-filling, or screenshot verification via the Browser pane tools fails or times out, even though the page itself loaded correctly (confirmed independently via get_page_text). Workaround in use: avoid Browser pane tools entirely and rely on get_page_text/WebFetch/other MCP automation (e.g. NotebookLM's own browser automation, which is unaffected) until this is fixed.

Environment

• Reported via a user session on 2026-08-05.
• Reproduced 3 consecutive times in the same session before switching to the workaround above.

---
Filed for posterity at the reporting user's request, cross-referencing internal ticket PBC #2385-3921-0706.