/fast {on|off|status} goes through to chat rather than being handled by the internal command processor
Open 💬 3 comments Opened Jul 1, 2026 by tbreeds-nv
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex CLI is running?
codex-cli 0.142.5
What subscription do you have?
nvidia?
Which model were you using?
gpt-5.5
What platform is your computer?
Linux 5b77c80-lcelt 6.17.0-35-generic #35~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 19:30:42 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
What terminal emulator and version are you using (if applicable)?
gnome-terminal
Codex doctor report
What issue are you seeing?
When running /fast off the message is going through to the chat like a normal message rather than being handled as a command. Same with /fast status. I can use /fast as a toggle but that doesn't match the documentation.
What steps can reproduce the bug?
Uploaded thread: 019f1b4c-5f68-71a2-83be-548fbcca0918
What is the expected behavior?
/fast off should disable Fast mode.
/fast status should report whether Fast mode is on or off.
Neither command should be sent to the assistant as chat text.
Additional information
Docs say /fast on, /fast off, and /fast status are valid
Repro steps
- Start codex-cli 0.142.5.
- Confirm banner shows gpt-5.5 xhigh fast.
- Type /fast off at the start of the TUI composer.
- Observe it is submitted as a normal chat message.
- Repeat with /fast status.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I also encountered this problem.
I verified this against the current sources, and this is a regression.
/fastused to be a hardcoded built-in slash command. In 2f5b01abd6, it supported:``
text
``/fast [on|off|status]
The regression appears to come from 7c0e54bf59, which generalized service-tier slash commands and removed the hardcoded
/fastcommand. Bare/faststill works, butdynamic service-tier commands currently report
supports_inline_args = false, so/fast offand/fast statusare not parsed as commands and fall through as regular prompt text.I made a small patch that restores inline-argument handling for dynamic service-tier commands. It adds coverage for:
/fast offresetting the service tier todefault/fast off/fast offI am not able to open a PR, so I am attaching the patch here instead. The patch was entirely vibecoded using Codex.
Patch attached:
codex-fast-off-regression.patch
Validation run locally:
``
sh
``just fmt
just test -p codex-tui fast_slash_command_off_arg_disables_fast_without_user_turn
just test -p codex-tui service_tier_slash_command_with_args_dispatches_from_catalog_name
just test -p codex-tui
Final package test result:
``
text
``2952 passed, 4 skipped
Confirmed and fixed. Bare
/fasttoggles, but/fast offand/fast statusfell through to the model as chat because service-tier commands reported no inline-argument support (SlashCommandItem::supports_inline_argsreturned false for theServiceTiervariant), and both dispatch paths only accepted builtin commands with arguments, so the service-tier-with-args case landed on the submit-as-user-message fallback.Fix: treat service-tier commands as inline-arg commands and route the argument to a dedicated handler.
on/enableset the tier explicitly (the bare command toggles, which is whyon/offare the useful spelling),off/disablereset to the default,statusreports the current state, and anything else prints a usage hint. Both the immediate composer path and the queued path (commands typed while a turn is running) are covered.Tests: a direct handler test covering on/off/status, plus a composer-routing test that submits
/fast offand asserts it resets the tier as a command rather than being sent as chat (the buggy path would not emit the tier override). The tui suite passes, and rustfmt and clippy are clean.Branch: https://github.com/abhay-codes07/codex/tree/fix/fast-slash-command-args
External PRs are invite-only here, so I am leaving it as a branch; happy to open one.