[BUG] Desktop: detached window ("Open in → New window") serves a stale "Plan usage limits" snapshot — 5-hour limit stuck at pre-reset value (still reproduces after updating)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A session detached into its own window via Open in → New window keeps serving a stale
Plan usage limits snapshot. The account-level 5-hour and weekly figures shown there can
be significantly out of date, while the main window shows the correct values.

This still reproduces after updating. I recorded it twice; the post-update recording is the
stronger of the two.

Recording 2 (post-update, primary evidence)

Two windows, both named in the Alt+Tab at 0:15: Claude (main, has the session sidebar) and
Caravela CRM — Projeto… (detached).

| | 0:02–0:07 detached | 0:18–0:22 main | 0:26 detached again |
|---|---|---|---|
| Context window | 736.8k / 1.0M (74%) | 113.4k / 1.0M (11%) | 736.8k / 1.0M (74%) |
| 5-hour limit | Resets in 3 hr 7 min · 24% | Resets in 3 hr 6 min · 34% | Resets in 3 hr 6 min · 34% |
| Weekly · all models | Resets Mon 12:00 AM · 89% | Resets Sun 11:59 PM · 90% | Resets Sun 11:59 PM · 90% |
| Weekly bar colour | yellow | red | red |

The decisive detail is that the reset label itself changed rendering. The detached window
showed Resets Mon 12:00 AM; after I focused the main window, that same row rendered as
Resets Sun 11:59 PM. That is the same instant formatted differently. Token consumption
cannot change how a timestamp is formatted, so the two renders must have come from different
data payloads — not merely different usage levels. This holds regardless of how fast usage
was actually being consumed in the background.

Corroborating: the countdown advanced only one minute (3 hr 7 min → 3 hr 6 min) while the
displayed 5-hour figure jumped 10 points, and it had been frozen at exactly 24% for 5+
seconds beforehand. The direction is self-consistent too — an older snapshot shows less
accumulated usage.

Recording 1 (original, corroborating)

Same behaviour, opposite direction and a much larger gap. The detached window showed a
5-hour limit of 58% when the real value was 4%. That row read Resets in 4 hr 33 min,
which means the current 5-hour window had begun 27 minutes earlier — so the 58% was the
accumulated usage of the previous, already-expired window. In that recording the stale row
was also missing the Resets in … label entirely.

Not affected

The context window figure shows no staleness in either recording (736.8k before and after
in recording 2, 705.6k in recording 1) — consistent with no turns being sent in those
sessions. The defect is specific to the Plan usage limits block.

These are account-level figures, not per-session. Two windows of the same app on the same
account cannot legitimately disagree.

What Should Happen?

Plan usage limits are account-global. Every window — main or detached — should show the same
values, refreshed on the same schedule, regardless of which window currently has focus. A
detached window should have its own refresh cycle rather than depending on activity in the
main window.

Error Messages/Logs

None. No error, warning, or log entry is surfaced. The detached window renders the stale value
with no indication that the data is not current. The silent nature of the failure is part of
the problem: there is no way for me to tell that the usage figure I am looking at is wrong.

Steps to Reproduce

1. Open the Claude Code desktop app (main window).
2. Detach a session into its own window with Open in → New window.
3. Leave the detached window focused while usage accrues elsewhere — from the main window,

another session, or background agents — or simply idle across a 5-hour-limit rollover.

1. In the detached window, open the usage meter below the composer.

→ The "Plan usage limits" block shows stale values.

1. Focus the main window and open its usage meter. It shows the correct values.
2. Return to the detached window and open the meter again.

→ It now shows the correct values.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Version 1.25927.0 (003700)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment detail not covered by the fields above

• This is the Claude Code desktop app on Windows 11, not a terminal session — I selected

"Other" for Terminal/Shell for that reason.

• The "Claude Code Version" field asks for claude --version, which reports the standalone

CLI on my PATH (2.1.170). That is a separate install from the desktop app, and this bug is
in the desktop GUI, so I entered the app's own version from its About dialog instead.

• Plan: Max (5x)

Why this can't be captured side-by-side (and what that implies)

I can't photograph the two windows showing the contradictory values at the same moment:
focusing the main window is itself what repairs the detached one. Observing the correct value
destroys the stale one.

That constraint is informative on its own. It suggests the detached window has no independent
refresh cycle for plan usage at all — it only receives updates as a side effect of main-window
activity. I can't isolate whether the trigger is window focus or opening the meter
specifically, since both happen together in my recordings and there's no way to separate them
from outside the app.

The staleness itself doesn't depend on capturing both at once. In recording 2 the reset label
changes rendering, which usage alone cannot explain. In recording 1 the Resets in 4 hr 33 min
countdown proves the 58% was already wrong when the recording started.

Possibly related

Same "detached window doesn't get its own state" cluster:

• #63016 — detached window: no per-window controls, Ctrl +/- routed to the main window
• #67390 — back navigation shared across windows on the same session
• #63895 — caret can't be placed inside text in a detached session window
• #32907 — "Open in New Window" creates an auxiliary window not visible in Alt+Tab

Possibly worth a look alongside #84257, which reports hangs in "New window" sessions and uses
flat token usage as an idleness signal — if usage readings in detached windows can be stale,
that signal may need independent verification there. Different symptom; I'm not claiming a
duplicate.

Attachments

• Post-update recording — primary evidence (5-hour 24% vs 34%, reset label changes rendering)
• Original recording (5-hour 58% vs 4%, provably 27 minutes stale)
• Two extracted frames from the original recording (0:03 and 0:27)

https://github.com/user-attachments/assets/1bb5a5ee-07d6-4faa-ab10-a19071650828
https://github.com/user-attachments/assets/282ab40e-0546-4c31-93f0-6c49d3c6d82a