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.
AI Agents panel: Codex tab stuck showing "initialize" (invalid --ask-for-approval value 'untrusted')
Reported by eddownes · filed Aug 24, 2026Closed upstream on 2026-08-25 by the bot omarchybot; the closing comment says it was fixed by PR #7649. 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 "AI Agents" bar plugin's Codex tab shows a persistent error card reading "initialize" instead of Codex's usage/rate-limit data, in place of the plan line.
Root cause
bin/omarchy-agent-usage-codex spawns:
codex -s read-only -a untrusted app-serverCurrent Codex CLI (codex-cli 0.149.1) rejects untrusted as a value for -a/--ask-for-approval:
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
[possible values: on-request, never]So the app-server process exits immediately (exit code 2) before it ever speaks JSON-RPC. rpc_request() in the collector then times out waiting for a response to its "initialize" call and raises TimeoutError("initialize"), whose message ("initialize") is what ends up in authHelpText and gets rendered in the panel.
This is not an auth/login issue — codex doctor and codex login status both report healthy (logged in via ChatGPT, Plus plan, websocket connectivity OK).
Verified fix
Changing the approval-policy value from untrusted to never (a currently-valid value) makes the RPC handshake succeed and returns real account/rate-limit data:
codex -s read-only -a never app-serverReproduced by hand:
$ codex -s read-only -a untrusted app-server
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' [possible values: on-request, never]
$ codex -s read-only -a never app-server
# ... RPC handshake succeeds, initialize/account/read/rateLimits/read all return valid resultsSteps to reproduce
- Install/update Codex CLI to a version where
--ask-for-approvalno longer acceptsuntrusted(0.149.1 confirmed). - Open the AI Agents bar panel, select the Codex tab.
- Observe the plan/status line is replaced by "Codex limits unavailable" and the help card shows "initialize".
System details
- Omarchy version: 4.0.0-1
- OS: Omarchy (Arch Linux),
7.1.8-arch1-3x86_64 - Codex CLI:
codex-cli 0.149.1(installed via mise) omarchy debugcommand does not exist in this Omarchy version (omarchy commands --allhas no debug entry), so no diagnostic log/URL is attached.
Suggested fix
In bin/omarchy-agent-usage-codex, change the app-server invocation's approval-policy flag from untrusted to never (or otherwise make it resilient to future renames of accepted values, e.g. try never and fall back to omitting -a on failure).
View raw text
## What happened
The "AI Agents" bar plugin's Codex tab shows a persistent error card reading **"initialize"** instead of Codex's usage/rate-limit data, in place of the plan line.
## Root cause
`bin/omarchy-agent-usage-codex` spawns:
```
codex -s read-only -a untrusted app-server
```
Current Codex CLI (`codex-cli 0.149.1`) rejects `untrusted` as a value for `-a`/`--ask-for-approval`:
```
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
[possible values: on-request, never]
```
So the `app-server` process exits immediately (exit code 2) before it ever speaks JSON-RPC. `rpc_request()` in the collector then times out waiting for a response to its `"initialize"` call and raises `TimeoutError("initialize")`, whose message (`"initialize"`) is what ends up in `authHelpText` and gets rendered in the panel.
This is *not* an auth/login issue — `codex doctor` and `codex login status` both report healthy (logged in via ChatGPT, Plus plan, websocket connectivity OK).
## Verified fix
Changing the approval-policy value from `untrusted` to `never` (a currently-valid value) makes the RPC handshake succeed and returns real account/rate-limit data:
```
codex -s read-only -a never app-server
```
Reproduced by hand:
```
$ codex -s read-only -a untrusted app-server
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' [possible values: on-request, never]
$ codex -s read-only -a never app-server
# ... RPC handshake succeeds, initialize/account/read/rateLimits/read all return valid results
```
## Steps to reproduce
1. Install/update Codex CLI to a version where `--ask-for-approval` no longer accepts `untrusted` (0.149.1 confirmed).
2. Open the AI Agents bar panel, select the Codex tab.
3. Observe the plan/status line is replaced by "Codex limits unavailable" and the help card shows "initialize".
## System details
- Omarchy version: 4.0.0-1
- OS: Omarchy (Arch Linux), `7.1.8-arch1-3` x86_64
- Codex CLI: `codex-cli 0.149.1` (installed via mise)
- `omarchy debug` command does not exist in this Omarchy version (`omarchy commands --all` has no debug entry), so no diagnostic log/URL is attached.
## Suggested fix
In `bin/omarchy-agent-usage-codex`, change the `app-server` invocation's approval-policy flag from `untrusted` to `never` (or otherwise make it resilient to future renames of accepted values, e.g. try `never` and fall back to omitting `-a` on failure).
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.