[Bug]: Pop-up resizing glitch on Codex tab

[ITensEI]

Existing issues

• I searched existing issues and did not find a duplicate.

What happened?

Opening the pop-up from the tray and selecting Codex the pop-up begins jumping and resizing. Behavior seems to only happen on the Codex tab.

Affected area

• Tray panel
• Settings UI
• Config file / settings persistence
• CLI
• Provider-specific behavior
• Installer / release packaging
• Startup / background behavior
• Other

Steps to reproduce

1. Double click tray icon
2. Click Codex tab

Logs, screenshots, or recordings

App version

v0.47.0

Windows version

Windows 11 Pro 25H2

Additional context

No response

[Finesssee]

Thanks for the issue, I will fix this ASAP.

[Finesssee]

Thanks for the video — we reproduced the exact setup on a debug v0.47.0 build (tray flyout -> Codex tab) and could NOT get the loop on Windows display-scale 1.0 or 125/150% presets: 9 configurations sampled at 300-400ms all converge to one rect and stay pixel-identical for 60s+, with consecutive screenshots diffing to 0 changed pixels. The other provider tabs in our test are static error cards (same as apparently in your build), which matches why only Codex repaints.

The flyout resize mechanism (useTrayPanelLayout: ResizeObserver -> debounce -> clamp + re-anchor) is idempotent unless the DOM keeps changing — so something inside the Codex card must be mutating every ~1s on your machine. Codex-only dynamic elements we audited: reset timers tick every 30s (too slow to oscillate per-second), chart animations end within 700ms, and pace strings only recompute on render.

Could you help us pin the driver with three quick data points?

1. Your Windows display scale (Settings -> Display -> Scale, e.g. 150%)? The flyout in your video looks ~143-150% relative to 1.0.
2. Does the loop STILL run after the tray has sat untouched (no refresh) for a full minute, or does it start right after a provider refresh event?
3. Does it stop if you disable Show Notifications (or the animated sections) temporarily, and does it also loop on the PopOut window (double-click a card) or only the single flyout?

If you can also attach a 5-10s recording where the window's mutation cadence is visible, or the exact Codex card content (do you have "Reset credits" or a long "Top model:" name wrapping to two lines?), we can reproduce the exact canvas-observer trigger and fix it rather than guessing.

[Finesssee]

Quick extra ask while you're looking, @ITensEI — one thing would discriminate the driver for us without any code changes on your side.

When the Codex-tab pop-up is looping, record ~8 seconds of it ON VIDEO and watch the movement's cadence:

1. Is the resize smooth and roughly rhythmic (≈1x every second, metronomic) — that means a DOM element that re-renders every ~1s (e.g. a ticking timer string changing width) and we have a short suspect list to fix.
2. Or is it jumpy/sporadic (bunches of motion, runs for 3-5s then stops, comes back after a provider refresh or window event) — that means a resize storm after the periodic refresh, a very different fix path.

If you can attach the clip (or even just tell us which of the two patterns you see), plus your display-scale percentage, we can cut the fix precisely instead of guessing. (For the technical context: the flyout's ResizeObserver layout path has been ruled out as the source of self-oscillation in our tests — the loop needs a periodic DOM mutation inside the Codex card, and cadence is what tells us which one your machine has.)

[Finesssee]

Seeded, deterministic repro rig — result: loop does NOT reproduce on our hardware; driver still open.

We built a provider-snapshot seed into the proof harness so the reporter's exact card content can be injected without live account data: launching the shell with CODEXBAR_SEED_USAGE_JSON=<path> plants one synthetic bridge-shaped Codex ProviderUsageSnapshot into the provider cache before the first WebView read (pinned against refresh eviction for the run), and a synthetic CODEX_HOME session rollout makes the local-usage chart block deterministic. With that we can reproduce the reporter's canvas 1:1 on demand: long wrapping Top model: gpt-5.6-sol-line-break-wrap-test (two lines), Reset credits extra window, weekly at 74%, ticking relative reset text, cost group — on the ambient Codex provider card in the tray flyout, at tray zoom 150%, flyout auto-fit active (remembered flyout size stripped), no other providers cached.

Instrumentation: WebView2 CDP attach (--remote-debugging-port=9222) + temporary probe in useTrayPanelLayout.resize() reporting every ResizeObserver fire, measure pass, scrollHeight/rect/committed height; WIN32 rect sampled 24× at ~400 ms; 12 desktop screenshots at 2 s; 30 fps video with frame-level panel-span analysis.

Measurement (all configs converge; no oscillation):

config	settle rect	oscillating
full reporter set	328×568	no
minus Top-model/local block	328×536	no
minus reset-credits	328×568	no
minus cost group	328×568	no
zoom 100 control	328×568	no
zoom 200	328×568	no
zoom 150 @ webview scale 1.0	328×636 / 328×842	no

Every run performs 2–3 auto-fit passes (initial min-height → chart-data arrival) and settles within ~2.5 s of opening the Codex tab; afterwards 24 samples are pixel-identical. Across 155 s — four 30 s reset ticks — the probe counters stayed flat: the ticking reset text re-renders without changing the surface box, so ResizeObserver never fires and no resize pass happens at all. No single-element removal changes stability; toggles only shift the converged height. (The layout engine in v0.47.0 and current main is byte-identical except MenuCard.tsx +6 lines for the accounts menu, which renders null at ≤1 account, so seed runs on main are a valid stand-in for the reporter's build.)

So, per-candidate judgment on our boxes: ticking reset text (30 s, zero ResizeObserver), long top model (arrives once with chart data), extra windows, cost — none can drive a loop by themselves here. The loop needs a DOM mutation we still haven't identified on the reporter's machine, OR a Win11-specific interaction (reporter is on 25H2; our repro rigs are Win10).

Two adjacent real defects did surface while at zoom >100% and will be handled separately (not claimed as the #261 driver): (1) scrollHeight is zoom-invariant while the card renders zoomed, so auto-fit sizes the window to pre-zoom units — at tray zoom 150% the card is clipped below the fold and a horizontal scrollbar appears (useTrayPanelLayout measure block vs TrayPanel.tsx style={{ zoom }}); (2) proof-harness anchor overflow at tall content, harness-only.

@ITensEI — the one measurement we cannot fake is your box. When the window is looping, could you run this once? Open regedit, save a note of HKCU\Control Panel\Desktop\WindowMetrics AppliedDPI, and tell us: is the resize (1) metronomic (~once per second, rhythmic) or (2) bursty (3–5 s run, then quiet until a refresh)? If you can also say whether Settings → Appearance "Show notifications"/animations are off, and whether the tray Zoom slider in the flyout footer was ever dragged, we can pin the last variable we can't see remotely.

[ITensEI]

Display: XG27ACS
Resolution: 2560x1440
Scale: 125%

Registry AppliedDPI: 0x00000078 (120)

Settings → Notifications → Show Notifications = true (disabling this doesn't change behavior)
Couldn't find the Animations setting.
Settings → Menu → Window scale = 100% (never changed)

The oscilation happens faster than once a second. See the attached video.
The zoom slider was never touched.
I noticed that while in the Codex tab if I click the on-pace budget and it pops out the graph the resizing stops.

Screen.Recording.2026-08-06.103206.mp4