agents: Claude limits freeze permanently after a backward clock step (negative cache age reads as fresh) #12305

What happened

After a backward system-clock correction, the Agents panel froze its Claude limits permanently: the Session (5-hour) row disappeared entirely and the two weekly rows kept showing percentages from hours earlier (74% / 67% when the account was actually at 82% / 80%). No error state, no "limits unavailable" — the panel just displayed confident, wrong numbers indefinitely.

Cause

omarchy-agent-usage-claude caches its probe result in ~/.cache/omarchy/agent-usage/claude-limits.json with a fetchedAtMs wall-clock stamp, and reuses it via:

fetched_at = number(cached.get("fetchedAtMs")) / 1000
if fallback and not force and time.time() - fetched_at < PROBE_MIN_INTERVAL_SECONDS:

The subtraction has no floor at zero. If the cache was written while the system clock was ahead — and it then steps back — time.time() - fetched_at is negative, which is always < PROBE_MIN_INTERVAL_SECONDS (15). The collector therefore treats the cache as fresh on every run and never re-probes, until real time catches up past the future-dated stamp.

On my machine the stamp was written an hour ahead, so the widget was frozen for an hour.

The disappearing session row is the second half of it, and it comes from a guard that is itself correct. limit_window_open() prunes any cached limit whose resetsAt has passed — right, since a stale 27% would misreport an allowance that has since reset. But with the re-probe suppressed, nothing replaces the pruned entry. So the short window (5-hour) silently vanishes while the long windows (7-day, not resetting until Saturday) survive and go stale in place. That asymmetry is what makes the panel look plausible rather than broken.

Concretely, from my cache at the time — note fetchedAtMs is one hour after the real time of the run:

{
  "fetchedAtMs": 1789670527513,          // 2026-09-17T18:42:07Z; actual time was 17:43Z
  "limits": [
    {"label": "Session (5-hour)", "percent": 0.27, "resetsAt": "2026-09-17T16:20:00Z"},  // pruned: window closed
    {"label": "Weekly (7-day)",   "percent": 0.74, "resetsAt": "2026-09-19T12:00:00Z"},  // kept, stale
    {"label": "Fable Weekly",     "percent": 0.67, "resetsAt": "2026-09-19T12:00:00Z"}   // kept, stale
  ]
}

Steps to reproduce

No clock manipulation needed — just forge the stamp:

python3 - <<'PY'
import json, time, pathlib
p = pathlib.Path.home() / ".cache/omarchy/agent-usage/claude-limits.json"
d = json.loads(p.read_text())
d["fetchedAtMs"] = round((time.time() + 3600) * 1000)   # 1h in the future
d["limits"] = [{"label": "Session (5-hour)", "percent": 0.01,
                "resetsAt": "2099-01-01T00:00:00+00:00"}]
p.write_text(json.dumps(d))
PY

omarchy-agent-usage-claude | jq '.limits'

Expected: a fresh probe, real percentages.
Actual: the sentinel 0.01 comes back, unchanged, on every subsequent run. --force correctly bypasses it and returns real numbers, which confirms the reuse branch is the culprit.

Suggested fix

Floor the age at zero, so a future-dated stamp reads as infinitely old rather than infinitely fresh:

age = max(0.0, time.time() - fetched_at)
if fallback and not force and age < PROBE_MIN_INTERVAL_SECONDS:

Optionally also discard a cache whose fetchedAtMs is implausibly far ahead of now, since the percentages it holds were measured against a clock that no longer agrees with the reset timestamps beside them.

Why the clock moved (may be worth a nudge elsewhere)

My RTC was configured in local time (timedatectl → RTC in local TZ: yes) with no Windows install on the machine to justify it. At boot the hardware clock is read as local, the system lands ahead, then NTP steps it back — which is exactly the trigger. timedatectl set-local-rtc 0 --adjust-system-clock fixed the underlying skew for me. Any Omarchy machine in that state will hit this, and the failure is silent.

Possibly related

#9382 (agents: Claude limits cache is shared across CLAUDE_CONFIG_DIR accounts) touches the same cache file, but is a different defect.

System

• Omarchy 4.0.3-1
• Kernel 7.2.3-arch1-3
• Intel Core Ultra 9 288V
• Python 3.14.7