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 panel: "Codex limits unavailable" because account/read hangs; limits are fetchable
Reported by sreshtasays · filed Oct 3, 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
What happens
The Agents panel's Codex tab intermittently shows "CODEX LIMITS UNAVAILABLE" with an error card reading account/read, even though Codex is logged in and its limits are available.
Cause
omarchy-agent-usage-codex (fetch_codex_rpc, lines 547–548) sends two app-server requests in sequence, each with a 4 s timeout:
account_msg = rpc_request(proc, 2, "account/read", timeout=4)
limits_msg = rpc_request(proc, 3, "account/rateLimits/read", timeout=4)With Codex CLI 0.160.0, account/read frequently never replies, while account/rateLimits/read sent afterwards on the same connection answers in under a second. The TimeoutError("account/read") aborts the whole fetch, so the limits are discarded and the panel shows the error.
Evidence
Probe: start codex -s read-only -a on-request app-server (the same command the collector uses), send initialize + initialized, then account/read and account/rateLimits/read, waiting up to 30 s for each. Six fresh processes:
| Run | initialize | account/read | account/rateLimits/read |
|---|---|---|---|
| 1 | 0.08 s | no reply in 30 s | 0.84 s |
| 2 | 0.10 s | no reply in 30 s | 0.88 s |
| 3 | 0.08 s | no reply in 30 s | 0.88 s |
| 4 | 0.09 s | no reply in 30 s | 0.80 s |
| 5 | 0.09 s | 0.50 s, ok | 0.85 s |
| 6 | 0.08 s | no reply in 30 s | 0.84 s |
Running omarchy-agent-usage-codex --limits-only six times gave 4 successes and 2 failures with authHelpText: "account/read". The machine was idle (load ≈ 1). The account/read params match Codex's own schema (GetAccountParams, all fields optional), so the request itself is well-formed. The hang may well be on the Codex side, but the collector does not need account/read to show limits.
Related
#7873 (fixed by #7649) failed one step earlier, at initialize, because the collector passed -a untrusted. That fix is present here (the collector launches with -a on-request) and initialize succeeds in ~0.1 s. This is the next failure point in the same function.
Suggested fix
account/rateLimits/read already returns planType, which line 552 prefers anyway (limits.get("planType") or account.get(...)). So:
- request
account/rateLimits/readfirst, and/or - treat
account/readas optional: catch its timeout and continue, usingrateLimits.planTypefor the tier label.
That way a slow or hung account/read can never hide limits that were available.
Steps to reproduce
- Codex CLI 0.160.0, logged in with a ChatGPT plan.
- Run
omarchy-agent-usage-codex --limits-onlyseveral times. - Some runs return no limits, with
usageStatusText: "Codex limits unavailable"andauthHelpText: "account/read".
System
- Omarchy 4.0.4-1 (
omarchy-agent-usage-codexfrom theomarchy4.0.4-1 package) - Codex CLI 0.160.0
- Arch Linux, kernel 7.2.5-3-omarchy
View raw text
### What happens
The Agents panel's Codex tab intermittently shows **"CODEX LIMITS UNAVAILABLE"** with an error card reading `account/read`, even though Codex is logged in and its limits are available.
### Cause
`omarchy-agent-usage-codex` (`fetch_codex_rpc`, lines 547–548) sends two app-server requests in sequence, each with a 4 s timeout:
```python
account_msg = rpc_request(proc, 2, "account/read", timeout=4)
limits_msg = rpc_request(proc, 3, "account/rateLimits/read", timeout=4)
```
With Codex CLI 0.160.0, `account/read` frequently never replies, while `account/rateLimits/read` sent afterwards on the same connection answers in under a second. The `TimeoutError("account/read")` aborts the whole fetch, so the limits are discarded and the panel shows the error.
### Evidence
Probe: start `codex -s read-only -a on-request app-server` (the same command the collector uses), send `initialize` + `initialized`, then `account/read` and `account/rateLimits/read`, waiting up to 30 s for each. Six fresh processes:
| Run | initialize | account/read | account/rateLimits/read |
| --- | --- | --- | --- |
| 1 | 0.08 s | no reply in 30 s | 0.84 s |
| 2 | 0.10 s | no reply in 30 s | 0.88 s |
| 3 | 0.08 s | no reply in 30 s | 0.88 s |
| 4 | 0.09 s | no reply in 30 s | 0.80 s |
| 5 | 0.09 s | 0.50 s, ok | 0.85 s |
| 6 | 0.08 s | no reply in 30 s | 0.84 s |
Running `omarchy-agent-usage-codex --limits-only` six times gave 4 successes and 2 failures with `authHelpText: "account/read"`. The machine was idle (load ≈ 1). The `account/read` params match Codex's own schema (`GetAccountParams`, all fields optional), so the request itself is well-formed. The hang may well be on the Codex side, but the collector does not need `account/read` to show limits.
### Related
#7873 (fixed by #7649) failed one step earlier, at `initialize`, because the collector passed `-a untrusted`. That fix is present here (the collector launches with `-a on-request`) and `initialize` succeeds in ~0.1 s. This is the next failure point in the same function.
### Suggested fix
`account/rateLimits/read` already returns `planType`, which line 552 prefers anyway (`limits.get("planType") or account.get(...)`). So:
- request `account/rateLimits/read` first, and/or
- treat `account/read` as optional: catch its timeout and continue, using `rateLimits.planType` for the tier label.
That way a slow or hung `account/read` can never hide limits that were available.
### Steps to reproduce
1. Codex CLI 0.160.0, logged in with a ChatGPT plan.
2. Run `omarchy-agent-usage-codex --limits-only` several times.
3. Some runs return no limits, with `usageStatusText: "Codex limits unavailable"` and `authHelpText: "account/read"`.
### System
- Omarchy 4.0.4-1 (`omarchy-agent-usage-codex` from the `omarchy` 4.0.4-1 package)
- Codex CLI 0.160.0
- Arch Linux, kernel 7.2.5-3-omarchy
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.