Codex usage collector passes removed '-a untrusted' flag, so limits never load #232

What happens

The Codex tab in the agents panel shows "Codex limits unavailable" with no plan
and no limit meters. Local token stats (tokens by day / by model) are correct —
only the limits and plan half is missing.

The written record looks like this:

{
  "usageStatusText": "Codex limits unavailable",
  "authHelpText": "initialize",
  "tierLabel": "",
  "limits": []
}

This is not an auth problem: ~/.codex/auth.json is valid and codex works
normally.

Cause

bin/omarchy-agent-usage-codex:531 starts the app-server with:

[codex, "-s", "read-only", "-a", "untrusted", "app-server"]

Current codex-cli no longer accepts untrusted as an --ask-for-approval
value. On codex-cli 0.149.1:

$ codex -s read-only -a untrusted app-server
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
  [possible values: on-request, never]

Codex exits with status 2 immediately. Because stderr is sent to DEVNULL
and Popen itself succeeds, the collector never notices — it waits on the
initialize RPC until the 8s timeout fires. The resulting TimeoutError
message is just the method name, which is why authHelpText reads
"initialize" rather than anything diagnostic.

Fix

Swapping untrusted for never restores the full chain — verified locally on
codex-cli 0.149.1, Arch Linux:

-      [codex, "-s", "read-only", "-a", "untrusted", "app-server"],
+      [codex, "-s", "read-only", "-a", "never", "app-server"],

account/read then returns the plan and account/rateLimits/read returns the
live windows, and the panel renders "Pro" with the weekly meter.

Dropping -a entirely also works and additionally surfaces the per-model
buckets in rateLimitsByLimitId (e.g. a 5h window for GPT-5.3-Codex-Spark),
though the collector only reads primary/secondary so the panel is
unaffected either way.

Possibly worth fixing alongside

Two things made this harder to diagnose than it needed to be:

1. stderr=subprocess.DEVNULL on the app-server Popen swallows the actual
   CLI error. Capturing it and including it in authHelpText on failure would
   have named the problem immediately.
2. A dead child is indistinguishable from a slow one — the collector burns the
   full 8s timeout on a process that already exited. A proc.poll() check on
   the timeout path (or a TimeoutError message that includes the exit status)
   would turn "initialize" into something actionable.

Environment

• omarchy 4.0.1rc3-1 (Arch package; /usr/bin/omarchy-agent-usage-codex)
• codex-cli 0.149.1
• Arch Linux, Python 3