[iaikanshb]

Summary

• bin/omarchy-agent-usage-codex spawns codex ... app-server with -a untrusted to probe account/read and account/rateLimits/read over RPC.
• The installed Codex CLI no longer accepts untrusted for -a/--ask-for-approval (only on-request/never remain), so the app-server subprocess exits immediately on the invalid argument and the collector's initialize RPC call just times out.
• Effect: the Agents bar widget shows "Codex limits unavailable" even when Codex is signed in and would otherwise report real rate-limit data.
• Fix: use never, the closest valid equivalent — the collector never sends a tool-execution request (only account/limits reads), so the approval policy is inert here; never keeps the headless probe from ever blocking on an unanswerable approval prompt.

Test plan

• Ran omarchy-agent-usage-codex --force before the fix: usageStatusText: "Codex limits unavailable", authHelpText: "initialize", limits: [].
• Ran it after the fix: real limits (weekly window %, reset time) and tierLabel populated.
• Ran omarchy-agent-usage-update and confirmed the on-disk record at ~/.local/state/omarchy/agents/usage/codex.json reflects the fix.
• Refreshed the running Agents bar panel via omarchy-shell omarchy.agents refresh and confirmed Codex now shows session/weekly limits alongside Claude.

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[omarchybot]

Thanks for tracking this down, @iaikanshb. quattro already carries a fix for the same bug: 4cd8a08 (#7649, merged 2026-08-25) changes the same -a untrusted in bin/omarchy-agent-usage-codex to -a on-request, and adds a regression check in test/shell.d/agent-usage-codex-scanner-test.sh that pins the argument list. That is why this pull request now conflicts with quattro.

For this collector the two values do the same thing: it only sends initialize, account/read and account/rateLimits/read, so nothing ever asks for approval, and never would add no behaviour over what is on quattro. Resolving the conflict in favour of never would also fail the scanner test, which expects on-request.

What was checked: the diff and quattro's history, read on the coordinator. Nothing was run on a worker, since the fix is already on the base branch. Codex Medium reviewed the same question separately and agreed it is already fixed by #7649 (independence not guaranteed); it added the point about the scanner test.

This waits on the maintainer, with a recommendation to close it as already fixed by #7649.

[omarchybot]

Thank you for this, @iaikanshb. quattro already fixes this (#7649), so it is closed as superseded.

Closed at the maintainer's request. The review comment above has the details; it was done by Claude Opus 5.5 with Codex Medium as a second opinion, whose agreement is not independent.