[BUG] Concurrent sessions on different accounts share rate-limit display — statusline `rate_limits` shows another account's 5h/7d usage (display-only)

Summary

On one machine running multiple concurrent Claude Code sessions logged into
different Claude accounts, the native rate_limits field that Claude Code
injects into the statusline stdin JSON is shared across all local sessions.

A session authenticated as Account A briefly shows Account A's own 5h/7d usage,
then ~15–20s after the conversation starts it is overwritten with Account B's
usage (B = the "primary"/most-active account). This is display-only —
billing/quota stays correctly per-account — but the statusline (and presumably
/usage) shows the wrong account's numbers.

Environment

• Claude Code 2.1.178 (native install), autoUpdates off
• macOS (Darwin 25.0.0), Apple Silicon (arm64)
• Account A: CLAUDE_CODE_OAUTH_TOKEN (setup-token) session
• Account B: interactive /login session (credentials in macOS Keychain)

Reproduction

1. Start a session for Account A: CLAUDE_CODE_OAUTH_TOKEN=<A> claude
2. Concurrently start a session for Account B (interactive /login)
3. Send a message in the Account A session, watch its statusline rate_limits

(five_hour / seven_day) over ~30s.

Expected: Account A's session shows Account A's own 5h/7d usage + reset times.
Actual: It shows its own values for a few seconds, then flips to Account B's
values within ~15–20s and stays there.

Evidence

Captured by tee-logging the exact stdin JSON handed to the statusline command
(resets_at are unix epochs; accounts anonymized):

# Account A session (env-token), right after first message:
  5h = 3%  @ 1781605200    7d = 27% @ 1781596800     <- A's own window
# ~11s later, SAME session:
  5h = 25% @ 1781600400    7d = 12% @ 1782108000     <- flipped to B's window
# Account B session (primary), throughout:
  5h = 25% @ 1781600400    7d = 12% @ 1782108000

The two accounts have genuinely distinct windows, yet after the flip both
sessions report byte-identical used_percentage AND resets_at -> the value
is read from a machine-shared source, not per-session.

Scope: display-only (billing is correct)

Account A genuinely has its own distinct 5h/7d window (@1781605200 /
@1781596800), confirming separate server-side quotas. Only the injected
rate_limits display is shared.

Regression

Appears tied to the background-session / Agent View coordination introduced
around 2.1.139. Local builds 2.1.175 / 2.1.177 / 2.1.178 are all affected.

Ruled out (no effect on the cross)

• CLAUDE_CODE_SUPPRESS_SESSION_ATTRIBUTION=1
• disableAgentView: true + CLAUDE_CODE_DISABLE_AGENT_VIEW=1
• The background daemon process isn't even running during the repro, yet the

cross still occurs — sharing appears to go via peer sockets
(~/.claude/daemon/roster.json has rendezvousSock entries), not a live daemon.

Mechanism hypothesis

The rate_limits injected into the statusline JSON is sourced from a
machine-global "current usage" state tied to the primary/most-active account
(one-account-per-machine assumption), which overwrites each session's own value
shortly after it connects.

Request

• Isolate the statusline rate_limits per session/account (don't broadcast

the primary account's usage to sessions authenticated as other accounts), or

• provide a supported flag to opt out of cross-session usage sharing.

Related

#54750 (attribution mismatch), #12786 (cross-account rate limit, same device),
#66528 (concurrent personal+work accounts), #34341 (multi-account failover).