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.
omarchy-agent-usage-codex: hardcoded --ask-for-approval value 'untrusted' rejected by current codex-cli
Reported by sal-he · filed Aug 31, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #8460 (R-1406). GitHub close reason: completed.
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 happened
The Agents bar widget's Codex rate-limit lookup always fails with usageStatusText: "Codex limits unavailable", even with a freshly-authenticated codex CLI.
Running the collector directly reproduces it:
$ omarchy-agent-usage-codex --force
{"schemaVersion":1,"id":"codex", ... ,"limits":[],"tierLabel":"","usageStatusText":"Codex limits unavailable","authHelpText":"initialize"}Root cause
omarchy-agent-usage-codex spawns the RPC subprocess with a hardcoded approval-policy flag:
[codex, "-s", "read-only", "-a", "untrusted", "app-server"]Running that exact command manually shows the actual failure — it's a CLI argument-parsing error, not an auth/RPC problem:
$ codex -s read-only -a untrusted app-server
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
[possible values: on-request, never]
For more information, try '--help'.The installed codex-cli (0.151.0) no longer accepts untrusted as a value for -a/--ask-for-approval — only on-request and never are valid now. The subprocess exits (code 2) before the JSON-RPC initialize handshake is ever sent, which is why the collector's error hint says "authHelpText":"initialize" even though authentication is fine (verified: ~/.codex/auth.json has a last_refresh from minutes before reproducing this).
Expected
The Codex tab in the Agents panel shows real rate-limit data for an authenticated codex CLI.
Actual
Codex never shows usable limits — "limits":[] and "usageStatusText":"Codex limits unavailable" — because the RPC subprocess fails to start.
Steps to reproduce
- Have
codex-cli0.151.0 (or any version where-a untrustedis invalid) onPATHand authenticated (codex login). - Run
omarchy-agent-usage-codex --force. - Observe
"limits":[]and"usageStatusText":"Codex limits unavailable"in the output, despite valid auth. - Confirm directly:
codex -s read-only -a untrusted app-server→error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'.
System details
- Omarchy version:
4.0.1-1 codex --version:codex-cli 0.151.0- Relevant file:
/usr/share/omarchy/bin/omarchy-agent-usage-codex(thefetch_codex_rpc()function,[codex, "-s", "read-only", "-a", "untrusted", "app-server"])
Suggested fix
Update the hardcoded value to one of the currently-valid options (never looks like the closest intent to a previous "untrusted" policy for a read-only, non-interactive usage probe), or detect the CLI's supported values before choosing one.
View raw text
## What happened
The Agents bar widget's Codex rate-limit lookup always fails with `usageStatusText: "Codex limits unavailable"`, even with a freshly-authenticated `codex` CLI.
Running the collector directly reproduces it:
```
$ omarchy-agent-usage-codex --force
{"schemaVersion":1,"id":"codex", ... ,"limits":[],"tierLabel":"","usageStatusText":"Codex limits unavailable","authHelpText":"initialize"}
```
## Root cause
`omarchy-agent-usage-codex` spawns the RPC subprocess with a hardcoded approval-policy flag:
```python
[codex, "-s", "read-only", "-a", "untrusted", "app-server"]
```
Running that exact command manually shows the actual failure — it's a CLI argument-parsing error, not an auth/RPC problem:
```
$ codex -s read-only -a untrusted app-server
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
[possible values: on-request, never]
For more information, try '--help'.
```
The installed `codex-cli` (0.151.0) no longer accepts `untrusted` as a value for `-a`/`--ask-for-approval` — only `on-request` and `never` are valid now. The subprocess exits (code 2) before the JSON-RPC `initialize` handshake is ever sent, which is why the collector's error hint says `"authHelpText":"initialize"` even though authentication is fine (verified: `~/.codex/auth.json` has a `last_refresh` from minutes before reproducing this).
## Expected
The Codex tab in the Agents panel shows real rate-limit data for an authenticated `codex` CLI.
## Actual
Codex never shows usable limits — `"limits":[]` and `"usageStatusText":"Codex limits unavailable"` — because the RPC subprocess fails to start.
## Steps to reproduce
1. Have `codex-cli` 0.151.0 (or any version where `-a untrusted` is invalid) on `PATH` and authenticated (`codex login`).
2. Run `omarchy-agent-usage-codex --force`.
3. Observe `"limits":[]` and `"usageStatusText":"Codex limits unavailable"` in the output, despite valid auth.
4. Confirm directly: `codex -s read-only -a untrusted app-server` → `error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'`.
## System details
- Omarchy version: `4.0.1-1`
- `codex --version`: `codex-cli 0.151.0`
- Relevant file: `/usr/share/omarchy/bin/omarchy-agent-usage-codex` (the `fetch_codex_rpc()` function, `[codex, "-s", "read-only", "-a", "untrusted", "app-server"]`)
## Suggested fix
Update the hardcoded value to one of the currently-valid options (`never` looks like the closest intent to a previous "untrusted" policy for a read-only, non-interactive usage probe), or detect the CLI's supported values before choosing one.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.