## 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:

```python
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:

```json
{
  "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:

```bash
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:

```python
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