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.
Codex usage collector rereads GB of history and saturates CPU
Reported by misunders2d · filed Sep 18, 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
System details
Intel Core Ultra 7 165U (14 logical CPUs), Intel Meteor Lake-P graphics, Omarchy 4.0.4-1, Linux 7.2.5-3-omarchy.
What's wrong?
omarchy-agent-usage-codex can saturate one CPU core for several minutes and make the desktop lag when Codex/Pi session history is large. The stock agents widget starts a normal collection immediately (triggeredOnStart: true) and repeats it on every refresh. A normal collection only reuses the local scan cache for 20 seconds, so each 15-minute refresh can walk the session history again.
Observed session data sizes:
~/.pi/agent/sessions: 409 MB~/.omp/agent/sessions: 1.1 GB~/.codex/sessions: 4.7 GB
Observed during one stock collector run:
omarchy-agent-usage-codex: 98-99% CPU for more than 3 minutes- process I/O counters: about 5.9 GB
rcharand 546k read syscalls - system load: 13-17; desktop visibly laggy
- memory pressure: zero; CPU temperature: 56 C
After terminating the collector, the machine returned to 98% idle. The configured widget is a user clone of omarchy.agents, but its Main.qml is byte-for-byte identical to the packaged stock plugin, and the heavy process is the packaged /usr/share/omarchy/bin/omarchy-agent-usage-codex collector.
Steps to reproduce:
- Accumulate several GB of Codex/Pi/OMP JSONL session history.
- Enable the stock
omarchy.agentswidget, or runomarchy-agent-usage-codexdirectly after its 20-second cache window expires. - Observe the collector consuming one core while recursively scanning/parsing session files for minutes.
- Wait for the widget's normal refresh interval; the full scan happens again.
Relevant implementation details in 4.0.4-1:
SCAN_REUSE_SECONDS = 20scan_pi_sessions()runsrgacross all Pi and OMP session roots without a date cutoff.scan_native_codex_sessions()opens and parses every JSONL file modified in the last 30 days.- The normal widget timer calls
runUpdate("normal"), including at startup.
Expected: periodic usage refresh should not rescan gigabytes of unchanged history or degrade desktop responsiveness. Possible approaches: incremental per-file caching keyed by mtime/size, a longer-lived aggregate cache with only changed files rescanned, or running scheduled refreshes at low CPU/I/O priority while keeping an explicit force refresh.
View raw text
### System details
Intel Core Ultra 7 165U (14 logical CPUs), Intel Meteor Lake-P graphics, Omarchy 4.0.4-1, Linux 7.2.5-3-omarchy.
### What's wrong?
`omarchy-agent-usage-codex` can saturate one CPU core for several minutes and make the desktop lag when Codex/Pi session history is large. The stock agents widget starts a normal collection immediately (`triggeredOnStart: true`) and repeats it on every refresh. A normal collection only reuses the local scan cache for 20 seconds, so each 15-minute refresh can walk the session history again.
Observed session data sizes:
- `~/.pi/agent/sessions`: 409 MB
- `~/.omp/agent/sessions`: 1.1 GB
- `~/.codex/sessions`: 4.7 GB
Observed during one stock collector run:
- `omarchy-agent-usage-codex`: 98-99% CPU for more than 3 minutes
- process I/O counters: about 5.9 GB `rchar` and 546k read syscalls
- system load: 13-17; desktop visibly laggy
- memory pressure: zero; CPU temperature: 56 C
After terminating the collector, the machine returned to 98% idle. The configured widget is a user clone of `omarchy.agents`, but its `Main.qml` is byte-for-byte identical to the packaged stock plugin, and the heavy process is the packaged `/usr/share/omarchy/bin/omarchy-agent-usage-codex` collector.
Steps to reproduce:
1. Accumulate several GB of Codex/Pi/OMP JSONL session history.
2. Enable the stock `omarchy.agents` widget, or run `omarchy-agent-usage-codex` directly after its 20-second cache window expires.
3. Observe the collector consuming one core while recursively scanning/parsing session files for minutes.
4. Wait for the widget's normal refresh interval; the full scan happens again.
Relevant implementation details in 4.0.4-1:
- `SCAN_REUSE_SECONDS = 20`
- `scan_pi_sessions()` runs `rg` across all Pi and OMP session roots without a date cutoff.
- `scan_native_codex_sessions()` opens and parses every JSONL file modified in the last 30 days.
- The normal widget timer calls `runUpdate("normal")`, including at startup.
Expected: periodic usage refresh should not rescan gigabytes of unchanged history or degrade desktop responsiveness. Possible approaches: incremental per-file caching keyed by mtime/size, a longer-lived aggregate cache with only changed files rescanned, or running scheduled refreshes at low CPU/I/O priority while keeping an explicit force refresh.
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 15:35 UTC