[BUG] Auto-continue at usage-limit reset is offered in only one session — other concurrent macOS-app sessions stay parked until manually retried

What's Wrong?

When several Claude Code sessions are open in the macOS desktop app and the account hits its session limit, every session shows a limit dialog — but only one of them offers the auto-continue-at-reset affordance. The rest have to be restarted by hand after the reset, one at a time.

The dialog the other sessions get is:

Session limit reached Try again after your session limit resets. [View details] [Try again]

No checkbox, no auto-retry option — just a manual Try again. Only the first session to hit the limit shows a variant carrying an auto-retry checkbox (exact wording of that variant not captured).

Steps to Reproduce

1. On the macOS desktop app, open several Claude Code sessions and keep them working concurrently (in our case ~11 live sessions across one multi-repo workspace).
2. Let the account hit its session limit while more than one session is mid-turn.
3. Look at each session's limit dialog.
4. Wait past the reset time without touching anything.

Observed: the first session that hit the limit resumes on its own. Every other session still shows the dialog above and stays idle until someone clicks Try again in each one.

Expected: the auto-continue setting is account/app-level ("Continue automatically at usage limit"), so every interrupted session should resume at reset — or at minimum, every session's dialog should offer the same choice.

Corroboration from inside the first session

This report comes from a workspace where an agent session was mid-task when the limit hit. In the first session the feature demonstrably worked: at reset, a continuation prompt was injected automatically ("I hit my usage limit while you were working, but it has reset now. Please continue from where you left off.") and the session picked the task back up with no user typing. So the mechanism itself is functioning — the gap is that the affordance is only offered in one session per limit window.

Why it matters

Auto-continue's value is unattended resumption. A single-session user gets that; anyone running sessions in parallel gets it for exactly one session and manual restarts for the rest — which is the case where unattended resumption is worth the most. It also makes the reset moment lossy in a non-obvious way: the sessions that stay parked look identical to sessions that finished.

Possibly related

• #91535 — auto-continue doesn't fire for a detached tmux session; reporter's suspected cause is that the resume check is gated on an attached-client render/focus event rather than a background timer.
• #91493 — auto-continue doesn't resume workflows or subagents.

If #91535's suspicion is right, this may be the same root in a different shape: the resume being bound to one client/UI surface rather than to each session's own state. Filing separately because the reproduction is different (multiple attached sessions inside one desktop app, not an unattached pty) and either could be fixed without the other.

Environment

• Claude desktop app (macOS), bundle version 1.44121.4
• Multiple concurrent Claude Code sessions in the Code tab
• The claude binary on PATH is a separate Homebrew install (2.1.97) and is not what the app runs — noting it only so it isn't mistaken for the app's version. I wasn't able to read the app's embedded claude-code version from the bundle; happy to provide it if you can point me at where it's exposed.

What I could not verify

The dialog behaviour is user-observed. This report is written by an agent running inside one of the affected sessions, which can see its own auto-continuation but cannot inspect the app's UI or the other sessions' dialogs. The dialog text above is transcribed from a screenshot of the non-checkbox variant; the checkbox variant's exact wording is not recorded.