Browser pane: opening any overlay (Annotate, settings, viewport) zooms the page to 2x until it is dismissed; recurs on every activation

Status Open

Reported on v2.1.246

Maintainer reply None cached

Activity 0 comments · opened Sep 3, 2026

What happens

Activating any Browser-pane overlay zooms the page underneath to ~2×, anchored top-left, for as long as the overlay is open. Dismissing the overlay restores 1×.

The zoom is transient and tied to the overlay being active — it is not a stuck state. But once the pane enters this condition it happens on every activation. Tearing the pane down and rebuilding it clears the condition sometimes; restarting the app clears it reliably.

Confirmed on three separate controls, all behaving identically:

Annotate — the drawing overlay
Browser settings — the settings popover
Viewport / responsive control — the size picker

So it is not one feature: it is whatever the pane does to the view when it opens an overlay.

Why it makes Annotate unusable: the moment the overlay opens, the page jumps to 2× and only the top-left quadrant is visible. Whichever element you meant to annotate is now off-screen, so you cannot mark it. Closing the overlay to find the element again just restores 1×, and reopening re-zooms. There is no state in which the element and the annotation tool are on screen together.

The page renders correctly whenever no overlay is open, and DOM reads work throughout.

This machine is at 100% display scaling (1920×1080, LogPixels unset / 96 dpi), so the 2× is not inherited from OS scaling.

Expected

Opening a pane overlay leaves the page's zoom untouched.

What has been tried

| Tried | Result | Basis |
|---|---|---|
| Full pane teardown — tabs_close every tab, then preview_start | fixes it sometimes — intermittent, not reliable | observed directly |
| Restarting the desktop app | fixes it | observed directly |
| Ctrl+0 — reset window zoom | does not help | observed directly |
| resize_window({preset: "desktop"}) | unestablished | see note |
| Page reload / navigate to same URL | unestablished | see note |

The teardown being intermittently effective is consistent with the concurrency correlation below: it appears to work when fewer other panes are live.

Correction, and a warning about a dead end I went down. An earlier revision of this report listed the teardown, reload and resize_window as ruled out. Those conclusions came from checking devicePixelRatio after each attempt — which is not a valid test, so I am retracting them rather than leaving them to mislead. devicePixelRatio cannot detect this bug. A healthy pane here reports devicePixelRatio: 2, innerWidth/Height 1034×914, visualViewport.scale 1, and renders the full page correctly. An affected pane reports the same values — because the fault only manifests while an overlay is open, and a reading taken between activations is always normal. The only reliable check is to open an overlay and look. An even earlier revision proposed a DPR/zoom mechanism for the bug. That was inference, not measurement, and is also retracted.

Evidence

Two captures of the same page, same pane, seconds apart, no navigation or resize between them:

Annotate overlay open — the page is at 2×, cut off roughly a third of the way into the content area; the annotation toolbar is visible at the bottom. The settings and viewport popovers produce the same 2× view.
Overlay dismissed, same page — the full layout at 1×: nav at half the width of (1), full-width content, and the rest of the page visible below the fold shown in (1).

Capture (1) is exactly the top-left quadrant of capture (2), magnified 2×. Same DOM, same scroll position.

The screenshots are not attached. They show an internal workforce-analytics page containing named third-party individuals and their per-person working hours, so they cannot go on a public issue. Happy to send them to a maintainer privately. The 2×/quadrant relationship described above is the whole of what is diagnostically relevant in them.

Trigger: concurrent panes, not elapsed time

Originally the pane would enter this condition "after a few hours" and an app restart cleared it. It now enters it within minutes of a restart. I analysed my local session transcripts since 2026-08-25 to find out why.

83 Browser-pane failures (46 "pane is not displayed / not compositing frames", 30 UnknownVizError, 7 blank captures) across 541 screenshot attempts, plus 50 invocations of a close-and-reopen-the-pane routine.

Correlating each failure against how many other sessions touched a pane within ±15 minutes:

| Other sessions driving a pane | mean | median |
|---|---|---|
| At a failure (n=75) | 2.11 | 2 |
| At a normal moment (n=217 sampled) | 1.21 | 1 |

Distribution of failures by concurrent-session count:

0 other sessions: 10
1 other session:   6
2 other sessions: 36
3 other sessions: 12
4 other sessions: 11

87% of failures occur with at least one other session holding a pane; 79% with two or more. Sessions that use the pane most also fail most (21 failures / 70 overlay interactions; 16 / 44; 13 / 29).

This reads as contention across concurrently open Browser panes rather than a per-pane timer, and it explains both the original "after a few hours" behaviour (one or two panes) and the current "within minutes" behaviour (five to nine instances, several holding panes).

Note: this covers two distinct faults

The compositing failures counted above (UnknownVizError, blank captures, "not displayed") are cleared by a pane teardown, reliably and on the first try. The overlay zoom responds to it only intermittently. Both scale with concurrent panes, so they may share a root cause, but they respond differently and are probably worth triaging separately.

Steps to reproduce

Open several Claude Code sessions, three or more with an active Browser pane on a localhost dev server.
Work in them for a while, taking screenshots and using the pane's controls.
In one pane, click Annotate (or browser settings, or the viewport control).
The page jumps to ~2×, anchored top-left, while the overlay is open.
Dismiss the overlay — the page returns to 1×.
Reopen it — it zooms again, and keeps doing so. A pane teardown + rebuild sometimes clears the condition; an app restart always does.

Environment

Claude Desktop app: 1.40609.1 (Windows), bundling Claude Code 2.1.246
The app auto-updated mid-session: the bundled-skills cache showed 2.1.219 earlier in the same session and 2.1.246 afterwards. The behaviour was identical on both.
Not the CLI — I use the desktop app. (A separate claude CLI on PATH here reports 2.1.77 and is unrelated.)
OS: Windows 11 Pro 10.0.26200
Display: 1920×1080, 100% scaling, single monitor
Node: v24.18.1
Several concurrent Claude Code instances, typically 5–9, several with Browser panes on localhost dev servers

Related but distinct

#78765 — Browser pane screenshot/zoom hangs 30s: a hang, not a scale change.
#81664 — Desktop crashes during Browser-pane screenshot verification: crash, not zoom.
#34998 — feature request for zoom controls in the Preview panel: unrelated, but touches the same scaling surface.

I could not find an existing issue describing the overlay-activation zoom or the concurrency correlation.

View original on GitHub ↗