Agents panel keeps stale Claude usage for hours after the clock is set back at boot #9955

System details

11th Gen Intel Core i7-11370H, Intel Iris Xe + NVIDIA RTX 3050 Ti Mobile (Surface Laptop Studio, dual boot with Windows), Omarchy 4.0.2-1, kernel 7.1.9-arch1-2

What's wrong?

After rebooting into 4.0.2 the Agents panel showed Claude at Session 0%, Weekly 8%, and 1 prompt for the day, and kept showing that for about two hours while I was using Claude Code the whole time. Then it corrected itself on its own. Pressing refresh in the panel (--force) always gave fresh numbers. The automatic refreshes did not.

The update is not the cause. bin/omarchy-agent-usage-claude is byte-identical in 4.0.1, 4.0.2, and current quattro. The reboot just exposed an older bug.

Cause

This machine boots with its clock two hours ahead. The CMOS clock holds local time because of the Windows dual boot, Linux reads it as UTC, and systemd-timesyncd steps the clock back about 75 seconds after boot ("Clock change detected" in the journal). The shell starts at 52 seconds and the agents plugin collects right away, so the first omarchy-agent-usage-claude run writes every cache with a timestamp two hours in the future.

Both cache readers accept a negative age:

# finite scan cache (transcripts, pi/omp, opencode)
if time.time() - path.stat().st_mtime <= max_age_seconds:

# 15-second probe throttle for claude-limits.json
if fallback and not force and time.time() - fetched_at < PROBE_MIN_INTERVAL_SECONDS:

A negative number is below every positive bound, so the scan cache stays "fresh" until its future mtime plus the TTL, and the limits throttle skips the probe until the future fetchedAtMs plus 15 seconds. That is the two-hour freeze and the automatic recovery.

The Codex collector already rejects a future-dated cache (#6780). The Claude collector does not, and its limits cache needs care because since #6795 it is also the last-known fallback when signed out or offline.

Reproduce without touching the clock

Both cases use temp directories and a stubbed usage endpoint. They are the two new assertions in the linked PR.

1. Run the collector once so it writes claude-scan-*.json, append one 10-token assistant record to the transcript, set the cache file's mtime one hour ahead, run the collector again. It returns the old total.
2. Write claude-limits.json with fetchedAtMs one hour ahead and an open Weekly window at 11%, give the collector a live token and a stub that answers 44%. It makes no request and returns 11%.

Expected: a future-dated scan cache is a miss, and a future fetchedAtMs does not suppress the automatic probe. If that probe fails, the still-open cached windows stay visible as before.

How common this is

The journal shows the same backwards step of about 7200 seconds on seven of the last eight boots here. Any dual-boot install that has not set timedatectl set-local-rtc 1 or RealTimeIsUniversal on the Windows side gets this at every boot. Other backwards corrections hit the same comparisons.

Fix: #9956