5-hour session reset time shifts forward by ~4 hours when new sessions open near window boundary

Environment

• Claude Code version: 2.1.118
• Plan: Team
• OS: macOS (Darwin 25.4.0)
• Date and timezone: 2026-04-23, America/Los_Angeles (PDT)

Summary

The 5-hour session reset time jumped forward ~4 hours about an hour before the window should have closed. No reset happened — the client just extended the window. The anchor was a single Haiku call, followed by ~3 hours of idle, followed by a burst of new sessions opened right before the displayed reset. The shift happened during that session burst.

Timeline

1. 06:17 AM PDT — Launchd-triggered claude -p call (Haiku, single prompt, --no-session-persistence) from a daily cron job. First Claude account activity of the day. Anchored the 5-hour window.
2. Through the morning — Statusline showed the reset at 11:00 AM PDT.
3. 09:54–10:12 AM PDT — Opened 5 Claude Code interactive sessions across different working directories in a 7-minute span. One opened near the 10:00 AM mark may have triggered the shift.
4. ~10:00 AM PDT — Displayed reset time jumped to 3:00 PM PDT. Window extended by ~4 hours.
5. 11:00 AM PDT — No reset. Usage kept going against the same session.

Expected behavior

A 5-hour window anchored at 06:17 resets at 11:17. If Claude Code recalculates the reset mid-session, document the trigger and show it in the UI.

Actual behavior

The displayed reset time shifted from 11:00 AM to 3:00 PM. No visible trigger. No reset event. No changelog entry explaining the recalculation.

Reproducer hypothesis

Concrete sequence:

1. Tiny prompt anchors the window (e.g., a cron job calling claude -p --model haiku).
2. Account idle for several hours.
3. Open multiple Claude Code sessions within a few minutes, near the original reset boundary.
4. Observe the displayed resets_at shift forward.

Impact

If you plan your work around the displayed reset time, you can't trust it. Here the shift gave me more time. But other open reports show the opposite — resets firing earlier than displayed (#49616), which silently burns usage.

Related issues

• #8958 — \"Usage Limit major leap.\" Closest match: reset time jumped forward on a later command. Closed as not planned.
• #51222 — Weekly reset displayed incorrectly (open, Apr 20, 2026). Same bug, weekly window.
• #49616 — Weekly limit reset 4+ hours before scheduled (open, Apr 17, 2026). Same thing in the other direction.
• #8739, #8926 — Older 5-hour inconsistencies. Both closed not planned.

Asks

1. Is the 5-hour window's displayed resets_at supposed to shift forward mid-session? If so, document the trigger.
2. If it's a bug, fix the client display so it always matches the server's reset time.
3. Reopen #8958 or consolidate with it — don't close it \"not planned\" again. This pattern has been around for 6+ months.