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 quota toggles between meters and "account/read": RPC timeout too tight, blank-on-failure wipes last-good limits
Reported by krsna1729 · filed Sep 24, 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
The agents panel Codex tab toggles between the real Session/Weekly meters and an empty state.
When empty, the record carries:
{"limits": [], "tierLabel": "", "usageStatusText": "Codex limits unavailable", "authHelpText": "account/read"}authHelpText is str(TimeoutError("account/read")) — the account/read RPC to the Codex
app-server timed out. The ChatGPT login itself is fine throughout (codex login status →
"Logged in using ChatGPT"); minutes later the same call succeeds and meters reappear.
Repro
Six sequential runs of the exact sequence fetch_codex_rpc() performs
(codex -s read-only -a on-request app-server, initialize, account/read with 4 s timeout):
run0: FAIL account/read after 4.16s
run1: FAIL account/read after 4.15s
run2: OK init=0.14s account=0.50s limits=0.68s
run3: OK init=0.13s account=0.47s limits=0.56s
run4: OK init=0.12s account=0.53s limits=1.09s
run5: FAIL account/read after 4.32s3/6 time out. Latency is bimodal: ~0.5 s normally, past 4 s on the slow path (same auth,
same machine, seconds apart).
Why the panel blanks instead of riding it out
Two compounding behaviors in the stock collectors:
omarchy-agent-usage-codex::fetch_codex_rpc()usestimeout=4foraccount/readwith no
retry, and on any exception returns limits: [] — but main() still exits 0 printing
valid JSON.
2. omarchy-agent-usage-update::collect() only keeps the old record when the collector exits
nonzero or prints invalid JSON. A valid-JSON-but-empty record overwrites last-good meters,
so one slow RPC blanks the tab until the next successful run (up to ~900 s).
Expected
Transient app-server slowness should not blank the meters: retry account/read (backoff and/or
a longer timeout — the slow path exceeds 4 s while the fast path is ~0.5 s), and if it still
fails, exit nonzero / print nothing so the updater keeps the last-good record. That is already
the contract the opencode-go adapter follows (exit 1 = no data, engine keeps previous
limits).
Environment
omarchy version: 4.0.4-1codex --version: codex-cli 0.156.1- ChatGPT Plus plan (two rate-limit windows)
- Full
omarchy debuglog available on request.
View raw text
## What happened
The agents panel Codex tab toggles between the real Session/Weekly meters and an empty state.
When empty, the record carries:
```json
{"limits": [], "tierLabel": "", "usageStatusText": "Codex limits unavailable", "authHelpText": "account/read"}
```
`authHelpText` is `str(TimeoutError("account/read"))` — the `account/read` RPC to the Codex
app-server timed out. The ChatGPT login itself is fine throughout (`codex login status` →
"Logged in using ChatGPT"); minutes later the same call succeeds and meters reappear.
## Repro
Six sequential runs of the exact sequence `fetch_codex_rpc()` performs
(`codex -s read-only -a on-request app-server`, `initialize`, `account/read` with 4 s timeout):
```
run0: FAIL account/read after 4.16s
run1: FAIL account/read after 4.15s
run2: OK init=0.14s account=0.50s limits=0.68s
run3: OK init=0.13s account=0.47s limits=0.56s
run4: OK init=0.12s account=0.53s limits=1.09s
run5: FAIL account/read after 4.32s
```
3/6 time out. Latency is bimodal: ~0.5 s normally, past 4 s on the slow path (same auth,
same machine, seconds apart).
## Why the panel blanks instead of riding it out
Two compounding behaviors in the stock collectors:
1. `omarchy-agent-usage-codex::fetch_codex_rpc()` uses `timeout=4` for `account/read` with no
retry, and on any exception returns `limits: []` — but `main()` still exits 0 printing
valid JSON.
2. `omarchy-agent-usage-update::collect()` only keeps the old record when the collector exits
nonzero or prints invalid JSON. A valid-JSON-but-empty record overwrites last-good meters,
so one slow RPC blanks the tab until the next successful run (up to ~900 s).
## Expected
Transient app-server slowness should not blank the meters: retry `account/read` (backoff and/or
a longer timeout — the slow path exceeds 4 s while the fast path is ~0.5 s), and if it still
fails, exit nonzero / print nothing so the updater keeps the last-good record. That is already
the contract the `opencode-go` adapter follows (`exit 1` = no data, engine keeps previous
limits).
## Environment
- `omarchy version`: 4.0.4-1
- `codex --version`: codex-cli 0.156.1
- ChatGPT Plus plan (two rate-limit windows)
- Full `omarchy debug` log available on request.
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 18:06 UTC