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 collector: intermittent account/read timeout blanks meters and never retries
Reported by KouenNoTen · filed Oct 5, 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
What happened
Every few panel opens / refreshes, the Codex tab loses its LIMITS meters and shows the status card Codex limits unavailable / account/read. The record at that point is "limits":[],"usageStatusText":"Codex limits unavailable","authHelpText":"account/read".
Why
Two compounding behaviors in omarchy-agent-usage-codex (fetch_codex_rpc):
- The
account/readRPC (4s timeout) intermittently never answers. Reproduced directly against onecodex app-server: most probes answer in ~0.5s, but roughly 1 in 5 hangs indefinitely (no answer in 20s+), including fully serial runs using the collector's exact message sequence. So it is the codex CLI stalling, not load or concurrency on the machine. - On any such failure the collector writes
"limits": []from scratch, wiping the last-known-good meters, and — unlike the retry-advised path other agents use — never setsretryAdvised. So nothing retries in 30s; recovery waits for the next 900s timer or panel reopen, which itself can fail again with ~20% probability.
Note authHelpText rendering the raw TimeoutError("account/read") string is what surfaces as the confusing account/read line in the panel.
Expected
A transient probe stall should not blank good data: preserve the previous record's limits across a failed probe and set retryAdvised so the panel retries soon (the Main.qml retry path already honors it per-agent).
Repro
Run 6 serial probes; expect ~1-2 to report the timeout:
for i in 1 2 3 4 5 6; do
omarchy-agent-usage-codex --limits-only | python3 -c "import json,sys; d=json.load(sys.stdin); print(len(d.get('limits',[])), d.get('authHelpText','OK'))"
done
Or speak raw RPC at one app-server: initialize, wait for the response, send initialized plus account/read — the account/read response intermittently never arrives.
Environment
omarchy version: 4.0.4-1 (note:omarchy debugdoes not exist on this version, so no debug log attached)codex --version: codex-cli 0.159.2- Arch Linux (Omarchy), Intel Core Ultra 9 275HX, 30 GiB RAM
No screenshot: the failure state is the standard status card plus empty LIMITS, fully described by the record snippet above.
View raw text
## What happened
Every few panel opens / refreshes, the Codex tab loses its LIMITS meters and shows the status card `Codex limits unavailable` / `account/read`. The record at that point is `"limits":[],"usageStatusText":"Codex limits unavailable","authHelpText":"account/read"`.
## Why
Two compounding behaviors in `omarchy-agent-usage-codex` (`fetch_codex_rpc`):
1. The `account/read` RPC (4s timeout) intermittently never answers. Reproduced directly against one `codex app-server`: most probes answer in ~0.5s, but roughly 1 in 5 hangs indefinitely (no answer in 20s+), including fully serial runs using the collector's exact message sequence. So it is the codex CLI stalling, not load or concurrency on the machine.
2. On any such failure the collector writes `"limits": []` from scratch, wiping the last-known-good meters, and — unlike the retry-advised path other agents use — never sets `retryAdvised`. So nothing retries in 30s; recovery waits for the next 900s timer or panel reopen, which itself can fail again with ~20% probability.
Note `authHelpText` rendering the raw `TimeoutError("account/read")` string is what surfaces as the confusing `account/read` line in the panel.
## Expected
A transient probe stall should not blank good data: preserve the previous record's limits across a failed probe and set `retryAdvised` so the panel retries soon (the `Main.qml` retry path already honors it per-agent).
## Repro
Run 6 serial probes; expect ~1-2 to report the timeout:
for i in 1 2 3 4 5 6; do
omarchy-agent-usage-codex --limits-only | python3 -c "import json,sys; d=json.load(sys.stdin); print(len(d.get('limits',[])), d.get('authHelpText','OK'))"
done
Or speak raw RPC at one app-server: initialize, wait for the response, send `initialized` plus `account/read` — the `account/read` response intermittently never arrives.
## Environment
- `omarchy version`: 4.0.4-1 (note: `omarchy debug` does not exist on this version, so no debug log attached)
- `codex --version`: codex-cli 0.159.2
- Arch Linux (Omarchy), Intel Core Ultra 9 275HX, 30 GiB RAM
No screenshot: the failure state is the standard status card plus empty LIMITS, fully described by the record snippet above.
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 21:29 UTC