You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Agents panel: Codex limits show 'initialize' — stale --ask-for-approval flag value #8849
Agents bar panel, Codex tab shows usage status "CODEX LIMITS UNAVAILABLE" and the auth-help card literally reads "initialize" instead of a helpful message.
Root cause
omarchy-agent-usage-codex collector launches the app-server with:
codex -s read-only -a untrusted app-server
-a untrusted is rejected by current codex-cli:
error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'
[possible values: on-request, never]
codex-cli process exits immediately, the RPC initialize call never gets a response, and the collector's rpc_request() raises TimeoutError("initialize"). That exception's str(exc) ("initialize") gets stored verbatim in authHelpText and shown in the panel — should instead surface a real "run codex login" / version-mismatch message, and the hardcoded flag value should track the current codex-cli approval-policy enum (on-request/never, no more untrusted).
Steps to reproduce
Install/update codex-cli to a version where --ask-for-approval no longer accepts untrusted (confirmed on codex-cli 0.149.0).
Log in with codex login, run at least one Codex session so local stats populate.
Open the Agents bar panel > Codex tab.
Local token stats show correctly; limits section shows "CODEX LIMITS UNAVAILABLE" and the help text is the bare string "initialize".
Expected
Either the collector uses a codex-cli-version-compatible flag, or the auth-help text explains the real failure (flag/version mismatch) instead of leaking the raw RPC method name.
System details
Omarchy version: 4.0.0-1
codex-cli version: 0.149.0 (installed via mise)
omarchy debug command does not exist in this Omarchy version (checked omarchy commands --all), so no diagnostic log attached.
Your "Expected" asks for one of two things, and they are landing separately — so this is worth untangling, because the root cause you diagnosed is half right and the half that is wrong explains why updating does not help.
The flag is no longer stale on the main branch.bin/omarchy-agent-usage-codex:531 on quattro already reads -a on-request, changed in 4cd8a08 ("Fix Codex usage collection on 0.149", #7649). What you are running is a package built before that commit: git tag --contains 4cd8a081 comes back empty and v4.0.1 is still the latest release, so the fix has never shipped to anyone. That is the whole of why 4.0.0/4.0.1 users keep reproducing this and why there is no update to pull.
The auth-help text is #8877, which I reviewed today (Claude Opus 5 in Claude Code, with an independent second opinion from Codex at xhigh). With it merged, a future flag rejection reads codex app-server exited: error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' instead of the bare initialize — I confirmed that output on a VM against the real codex-cli 0.150.1. It is not merged yet: I left a defect on it for its author, where any failure that leaves the app-server running now says "Run codex login" even to a user who is logged in.
So this issue is genuinely answered by the pair, and #8877 closing it is right. What it does not do is get either half onto your machine: until a release carries 4cd8a08, the installed /usr/share/omarchy/bin/omarchy-agent-usage-codex still passes untrusted and the panel stays empty. #8868, #8460 and #8398 are that same release gap and are not closed by #8877 — they are waiting on a maintainer to cut a release or ship a migration, which is not something a code change here can settle.
Automated duplication check: this issue looks similar to #8460, which covers the same Codex limits unavailable from stale approval flag. I keep that one open and close this one to keep the discussion in one place.
If you feel this is the wrong decision, please open the issue again with a note on the difference.
Activity
omarchybot commentedon Aug 29, 2026
Your "Expected" asks for one of two things, and they are landing separately — so this is worth untangling, because the root cause you diagnosed is half right and the half that is wrong explains why updating does not help.
The flag is no longer stale on the main branch.
bin/omarchy-agent-usage-codex:531onquattroalready reads-a on-request, changed in 4cd8a08 ("Fix Codex usage collection on 0.149", #7649). What you are running is a package built before that commit:git tag --contains 4cd8a081comes back empty andv4.0.1is still the latest release, so the fix has never shipped to anyone. That is the whole of why 4.0.0/4.0.1 users keep reproducing this and why there is no update to pull.The auth-help text is #8877, which I reviewed today (Claude Opus 5 in Claude Code, with an independent second opinion from Codex at xhigh). With it merged, a future flag rejection reads
codex app-server exited: error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'instead of the bareinitialize— I confirmed that output on a VM against the real codex-cli 0.150.1. It is not merged yet: I left a defect on it for its author, where any failure that leaves the app-server running now says "Runcodex login" even to a user who is logged in.So this issue is genuinely answered by the pair, and #8877 closing it is right. What it does not do is get either half onto your machine: until a release carries 4cd8a08, the installed
/usr/share/omarchy/bin/omarchy-agent-usage-codexstill passesuntrustedand the panel stays empty. #8868, #8460 and #8398 are that same release gap and are not closed by #8877 — they are waiting on a maintainer to cut a release or ship a migration, which is not something a code change here can settle.bjarneo commentedon Sep 20, 2026
Automated duplication check: this issue looks similar to #8460, which covers the same Codex limits unavailable from stale approval flag. I keep that one open and close this one to keep the discussion in one place.
If you feel this is the wrong decision, please open the issue again with a note on the difference.