Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Agents usage refresh: Claude collector rescans all transcripts every run (~15 s CPU), and collectors run for agents never signed in
Reported by dragosol · filed Oct 7, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Summary
The Agents panel's refresh (omarchy-agent-usage-update, every 15 min by default) costs far more than it needs to, in two ways:
- `omarchy-agent-usage-claude` re-reads every Claude Code transcript from scratch on every refresh. Its scan cache defaults to
--cache-seconds 20, but the panel refreshes every 900 s, so the cache never hits and each refresh is a fullrglob("*.jsonl")over~/.claude/projects. - Collectors run for agents that were never set up.
omarchy-agent-usage-codexstartscodex app-serverwhenevercodexis on PATH, even with no~/.codex/auth.json;omarchy-agent-usage-fireworksruns with no key and nofirectl. They return "unavailable" records every time.
Measurements
omarchy 4.0.4-1, Dell XPS 13 9350 (Lunar Lake, 16 GB), ~/.claude/projects = 2.6 GB / 361 transcripts. Each collector timed individually (wall time / CPU time of the process tree):
| collector | normal run | notes |
|---|---|---|
| claude | 41.6 s wall, 14.7 s CPU | full transcript rescan; a second run within 20 s takes 0.2 s (cache hit) |
| codex | 0.9 s wall, 0.8 s CPU, ~95 MB | not signed in (no ~/.codex/auth.json) — spawns codex app-server anyway |
| fireworks | 0.2 s | no API key, no firectl |
A system monitor on this laptop recorded the refresh as a ~10 s burst at 80–98 % of a core, every ~15 min. On a machine already short of memory, reading 2.6 GB of transcripts every 15 minutes also pushes useful pages out of the page cache, and the burst coincided with compositor stalls.
Suggestions
- Claude: make the scan incremental. Transcripts are append-only JSONL, so per-file
(size, mtime, byte offset)plus per-file aggregates kept in the existing cache dir would turn a refresh into reading only the new bytes. At minimum, default the scan cache to the panel's refresh interval rather than 20 s. - Unconfigured agents: give each collector a cheap "is this agent set up?" check (auth file present / API key configured / CLI logged in) and skip the expensive path, writing a minimal "not signed in" record. The codex collector could check for
~/.codex/auth.json(orCODEX_HOME) before startingcodex app-server. - Optionally, start collectors one at a time (or with
nice) instead of all in parallel with&, so a refresh doesn't arrive as a single burst.
Related collector reliability issues: #14359, #14293, #13880.
View raw text
### Summary
The Agents panel's refresh (`omarchy-agent-usage-update`, every 15 min by default) costs far more than it needs to, in two ways:
1. **`omarchy-agent-usage-claude` re-reads every Claude Code transcript from scratch on every refresh.** Its scan cache defaults to `--cache-seconds 20`, but the panel refreshes every 900 s, so the cache never hits and each refresh is a full `rglob("*.jsonl")` over `~/.claude/projects`.
2. **Collectors run for agents that were never set up.** `omarchy-agent-usage-codex` starts `codex app-server` whenever `codex` is on PATH, even with no `~/.codex/auth.json`; `omarchy-agent-usage-fireworks` runs with no key and no `firectl`. They return "unavailable" records every time.
### Measurements
omarchy 4.0.4-1, Dell XPS 13 9350 (Lunar Lake, 16 GB), `~/.claude/projects` = 2.6 GB / 361 transcripts. Each collector timed individually (wall time / CPU time of the process tree):
| collector | normal run | notes |
|---|---|---|
| claude | **41.6 s wall, 14.7 s CPU** | full transcript rescan; a second run within 20 s takes 0.2 s (cache hit) |
| codex | 0.9 s wall, 0.8 s CPU, ~95 MB | not signed in (no `~/.codex/auth.json`) — spawns `codex app-server` anyway |
| fireworks | 0.2 s | no API key, no `firectl` |
A system monitor on this laptop recorded the refresh as a ~10 s burst at 80–98 % of a core, every ~15 min. On a machine already short of memory, reading 2.6 GB of transcripts every 15 minutes also pushes useful pages out of the page cache, and the burst coincided with compositor stalls.
### Suggestions
- **Claude:** make the scan incremental. Transcripts are append-only JSONL, so per-file `(size, mtime, byte offset)` plus per-file aggregates kept in the existing cache dir would turn a refresh into reading only the new bytes. At minimum, default the scan cache to the panel's refresh interval rather than 20 s.
- **Unconfigured agents:** give each collector a cheap "is this agent set up?" check (auth file present / API key configured / CLI logged in) and skip the expensive path, writing a minimal "not signed in" record. The codex collector could check for `~/.codex/auth.json` (or `CODEX_HOME`) before starting `codex app-server`.
- Optionally, start collectors one at a time (or with `nice`) instead of all in parallel with `&`, so a refresh doesn't arrive as a single burst.
Related collector reliability issues: #14359, #14293, #13880.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 22:20 UTC