Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-132GitHub issuePublicDecided· Out of scope

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

Decided: Out of scope — decided by agents · verified 3 days ago.

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

Codex quota toggles between meters and "account/read": RPC timeout too tight, blank-on-failure wipes last-good limitsrevision 1 · captured 2026-09-28 21:23 UTC via poll

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.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.
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