What feature would you like to see?

Certain slash commands should act as steerable control-plane commands even while Codex is actively running, instead of being rejected until the current run completes.

In particular:

• /permission
• /fork
• likely a few other session-control commands

Current pain

Right now, if Codex is busy and I try one of these commands, the UI effectively says I cannot do that right now.

That forces an awkward choice:

• wait for the current operation to finish
• cancel the current operation just to issue the command

This is especially frustrating for /fork. Forking is often exactly what I want to do mid-run when I realize I want to branch the work without throwing away progress or waiting for a long operation to finish.

Expected behavior

Commands like /permission and /fork should be steerable during an active run, similar to other in-app steering behavior.

Possible semantics:

• /permission should open or update permission state immediately, or queue as a high-priority control action for the current run
• /fork should create a new fork from the current conversation state without forcing me to cancel the active operation
• if a command cannot be applied instantly, Codex should handle it as an interruptible or queued control action rather than a hard rejection

Why this matters

These are not normal content prompts; they are session and workflow controls.
Blocking them behind "wait until the run finishes" makes the UX worse in exactly the moments where users need the most control.

Scope

I am mainly asking for this in the Codex app, but the same principle should apply anywhere Codex exposes slash commands.

Additional information

This feels like a broader product rule:

• control-plane slash commands should remain available while a run is active
• only commands that truly cannot be reconciled with the current run should be blocked