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: Codex limits dropped when app-server never answers account/read
Reported by LeviWyattP · filed Sep 25, 2026Closed upstream on 2026-10-04 by the bot omarchybot. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
AMD Ryzen 9 9950X3D, NVIDIA RTX 5090, Omarchy 4.0.4-1, codex-cli 0.157.0
What's wrong?
The Agents panel often shows "Codex limits unavailable" with the detail account/read, even though Codex is signed in and its rate limits are readable.
omarchy-agent-usage-codex → fetch_codex_rpc() sends account/read (4s timeout) and then account/rateLimits/read inside one try. On this machine the app-server frequently never replies to `account/read`. The TimeoutError("account/read") then drops into the except, which discards the rate-limit request entirely, so the record ends up with limits: [].
Measured with the collector's exact sequence (initialize → initialized → account/read → account/rateLimits/read) over 8 fresh app-server processes:
| run | account/read | account/rateLimits/read |
|---|---|---|
| 0–3, 5 | no reply within 15s | ok in 0.3–0.75s |
| 4, 6, 7 | ok in 0.2–0.3s | ok in 0.3–0.9s |
So account/read fails about 5 times in 8, and rateLimits/read answers every time. Running the collector directly shows the same flip-flop: omarchy-agent-usage-codex --limits-only returned no limits on 3 of 4 runs and the weekly limit on the other.
Steps to reproduce
- Sign in to Codex (
codex login, ChatGPT Plus in my case). - Run
/usr/share/omarchy/bin/omarchy-agent-usage-codex --limits-only | jq '{usageStatusText, authHelpText, limits}'several times. - Most runs give
"usageStatusText": "Codex limits unavailable", "authHelpText": "account/read", "limits": [].
Suggested fix
account/read only supplies a fallback plan label (planType already comes from rateLimits first). Making it optional would keep the limits:
- request
account/rateLimits/readfirst, and/or - wrap
account/readin its owntrywith a short timeout, and keep going if it fails.
A local workaround that calls only account/rateLimits/read has returned limits on every run.
View raw text
### System details
AMD Ryzen 9 9950X3D, NVIDIA RTX 5090, Omarchy 4.0.4-1, codex-cli 0.157.0
### What's wrong?
The Agents panel often shows **"Codex limits unavailable"** with the detail `account/read`, even though Codex is signed in and its rate limits are readable.
`omarchy-agent-usage-codex` → `fetch_codex_rpc()` sends `account/read` (4s timeout) and then `account/rateLimits/read` inside one `try`. On this machine the app-server frequently **never replies to `account/read`**. The `TimeoutError("account/read")` then drops into the `except`, which discards the rate-limit request entirely, so the record ends up with `limits: []`.
Measured with the collector's exact sequence (`initialize` → `initialized` → `account/read` → `account/rateLimits/read`) over 8 fresh app-server processes:
| run | account/read | account/rateLimits/read |
|---|---|---|
| 0–3, 5 | no reply within 15s | ok in 0.3–0.75s |
| 4, 6, 7 | ok in 0.2–0.3s | ok in 0.3–0.9s |
So `account/read` fails about 5 times in 8, and `rateLimits/read` answers every time. Running the collector directly shows the same flip-flop: `omarchy-agent-usage-codex --limits-only` returned no limits on 3 of 4 runs and the weekly limit on the other.
### Steps to reproduce
1. Sign in to Codex (`codex login`, ChatGPT Plus in my case).
2. Run `/usr/share/omarchy/bin/omarchy-agent-usage-codex --limits-only | jq '{usageStatusText, authHelpText, limits}'` several times.
3. Most runs give `"usageStatusText": "Codex limits unavailable", "authHelpText": "account/read", "limits": []`.
### Suggested fix
`account/read` only supplies a fallback plan label (`planType` already comes from `rateLimits` first). Making it optional would keep the limits:
- request `account/rateLimits/read` first, and/or
- wrap `account/read` in its own `try` with a short timeout, and keep going if it fails.
A local workaround that calls only `account/rateLimits/read` has returned limits on every run.
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.
No decision has been recorded yet.