Proof Portal

Sign in
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-4780GitHub issuePublicReceived

omarchy-agent-usage-codex: RPC probe fails on current Codex CLI (-a untrusted no longer valid)

Reported by ddiall · 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.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

omarchy-agent-usage-codex: RPC probe fails on current Codex CLI (-a untrusted no longer valid)revision 1 · captured 2026-10-04 12:03 UTC via poll

What happened

The Codex collector for the Agents bar widget (omarchy-agent-usage-codex) invokes:

codex -s read-only -a untrusted app-server

On a current Codex CLI build, -a untrusted is rejected outright:

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

--ask-for-approval on this Codex build only accepts on-request or never — untrusted isn't a valid approval policy anymore. Because the subprocess exits immediately, the collector's initialize RPC call times out/fails, so account/read and account/rateLimits/read never run. The resulting usage record always has empty limits, empty tierLabel, and:

"usageStatusText": "Codex limits unavailable",
"authHelpText": "initialize"

Local usage stats (session-file scanning) still work fine and are unaffected — this only breaks the live rate-limit/plan RPC probe.

Expected

The collector should use an approval policy value that's valid for the installed Codex CLI, so account/read and account/rateLimits/read succeed and the Agents panel shows real limits/plan for Codex, the same way it does for Claude.

Steps to reproduce

  1. Install a current Codex CLI build (codex --version → codex-cli 0.151.0 in my case).
  2. Run a real Codex session so local stats are non-zero (so the tab appears in the Agents widget).
  3. Open the Agents bar panel → Codex tab shows "Codex limits unavailable" instead of a rate-limit meter.
  4. Or reproduce directly: codex -s read-only -a untrusted app-server → exits immediately with error: invalid value 'untrusted' for '--ask-for-approval'.

System details

  • Omarchy version: 4.0.1-1
  • Codex CLI version: codex-cli 0.151.0 (installed via mise)
  • codex --help confirms --ask-for-approval / -a only accepts on-request and never on this build.

Note: omarchy debug --no-sudo --print doesn't exist as a command on this Omarchy version (omarchy commands --all has no debug entry), so I couldn't attach that log — happy to provide anything else needed.

View raw text
## What happened

The Codex collector for the Agents bar widget (`omarchy-agent-usage-codex`) invokes:

```
codex -s read-only -a untrusted app-server
```

On a current Codex CLI build, `-a untrusted` is rejected outright:

```
$ 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'.
```

`--ask-for-approval` on this Codex build only accepts `on-request` or `never` — `untrusted` isn't a valid approval policy anymore. Because the subprocess exits immediately, the collector's `initialize` RPC call times out/fails, so `account/read` and `account/rateLimits/read` never run. The resulting usage record always has empty `limits`, empty `tierLabel`, and:

```json
"usageStatusText": "Codex limits unavailable",
"authHelpText": "initialize"
```

Local usage stats (session-file scanning) still work fine and are unaffected — this only breaks the live rate-limit/plan RPC probe.

## Expected

The collector should use an approval policy value that's valid for the installed Codex CLI, so `account/read` and `account/rateLimits/read` succeed and the Agents panel shows real limits/plan for Codex, the same way it does for Claude.

## Steps to reproduce

1. Install a current Codex CLI build (`codex --version` → `codex-cli 0.151.0` in my case).
2. Run a real Codex session so local stats are non-zero (so the tab appears in the Agents widget).
3. Open the Agents bar panel → Codex tab shows "Codex limits unavailable" instead of a rate-limit meter.
4. Or reproduce directly: `codex -s read-only -a untrusted app-server` → exits immediately with `error: invalid value 'untrusted' for '--ask-for-approval'`.

## System details

- Omarchy version: `4.0.1-1`
- Codex CLI version: `codex-cli 0.151.0` (installed via mise)
- `codex --help` confirms `--ask-for-approval` / `-a` only accepts `on-request` and `never` on this build.

Note: `omarchy debug --no-sudo --print` doesn't exist as a command on this Omarchy version (`omarchy commands --all` has no `debug` entry), so I couldn't attach that log — happy to provide anything else needed.

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.