Low-credit picker interrupts Codex CLI workflows
- severity/medium
---
Summary
When a workspace approaches its credit limit, Codex CLI replaces normal command output with an obtrusive “model picker” modal that insists you select a lower/cheaper model before it will continue. The picker steals the TUI focus, blocks stdin/stdout, and requires manual navigation before any command can continue. This is extremely disruptive for scripted usage because the picker expects a human to select an option, yet these flows run unattended inside tmux panes. The end result is another hard hang—no command output is produced, automation freezes, and we lose minutes of progress every time a workspace dips below the warning threshold.
Environment
- Codex CLI
0.57.0on macOS 26.0.1 (arm64) - Triggered through non-interactive tmux wrappers that call
codexinside automation scripts - Organization with multiple Codex workspaces; the picker appears as soon as the current workspace is flagged “low credit” (well before hitting 0 credits)
Steps to Reproduce
- Use a Codex workspace that is within ~10% of its credit allocation.
- Run any command, for example:
``bash``
codex run --repo . "npm test"
- Instead of streaming command output, the CLI clears the screen and renders a modal with buttons for “Switch workspace”, “Manage credits”, etc.
Expected Behavior
- Low-credit warnings should be informational: print a short message such as “Workspace X has <5% credits remaining” (or “Consider switching to a lighter model”) and let the requested command continue.
- Non-interactive invocations (no TTY, piped stdin, tmux panes) should never be blocked by marketing UI. The CLI should only emit text that scripts can parse and should exit normally.
Actual Behavior
- The picker captures focus and refuses to proceed until a user manually presses arrow keys / enter.
- Non-interactive wrappers wait forever because no output arrives; the dashboard stalls and the entire automation script gets stuck.
- Even after selecting any option (including “Continue”), the original command restarts from scratch, wasting minutes in longer jobs and forcing us to re-stream logs we already saw.
- There is no flag (
--no-upsell,--non-interactive) to disable the picker, so every workstation that is “low” wedged all of our automated/codextasks until a human babysat the pane.
Impact
- Breaks tmux automation: long-running
/codex …sessions freeze in mid-run. - Hard to triage: nothing meaningful is logged besides stalled “Processing request …” output, so remote teammates assume the job is still running.
- Forces context switching: engineers must stop coding, attach to the tmux session, acknowledge the picker, and re-run the command. This happens multiple times per day when juggling several workspaces.
- The upsell UI triggers even when a workspace still has enough credits for the current task, so it is pure friction rather than helpful telemetry.
Requested Fix
- Remove the interactive picker from the CLI entirely; suggestions to switch models should be text-only guidance that never blocks output.
- Replace it with a plain text warning (stderr) and let the command continue unabated so non-interactive workflows never pause.
- At minimum, provide an environment variable or CLI flag (
CODEX_NO_PICKER=1,--non-interactive) that guarantees Codex behaves like a normal CLI even on low credits. - Optionally surface the remaining credit count alongside the warning so scripts can decide whether to bail or continue.
Workaround
None that is viable for automation. The only option today is “watch every tmux pane and press Enter on the picker every time it appears,” which defeats the purpose of using Codex to run unattended workflows.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗