Feature request: Allow switching sandbox/approval mode within an active session

What variant of Codex are you using?

CLI

What feature would you like to see?

Summary

Currently, the sandbox mode (-s read-only / workspace-write / danger-full-access) and approval policy have to be decided at process start via CLI flags or config. Once a codex session is running, there is no way to switch modes without exiting and restarting the process — which loses the entire in-memory conversation context.

I would like to be able to switch sandbox / approval mode inside a live session, similar to how a slash-command or a runtime toggle would work.

Motivation / Use case

A very common workflow is:

1. Start a session in read-only mode to let codex explore the code, read files, and propose a plan.
2. Once I've reviewed the plan and want codex to actually apply edits, I need to escalate to workspace-write.
3. Occasionally, for a one-off shell command that touches something outside the workspace, I'd like to briefly grant danger-full-access, then drop back down.

Today the only way to do step 2 or step 3 is:

• Kill the current codex process
• Re-launch with a different -s flag
• Lose all conversation history, cached reasoning, and in-flight thread state

This is painful because the whole reason I ran the exploration phase read-only was to build up context safely. Throwing that context away just to change one flag defeats the purpose.

Proposed behavior

Any of these would solve it — listed in order of preference:

1. Slash command inside the session, e.g. /sandbox workspace-write or /approval on-request. Codex prints the old value → new value and continues the same thread.
2. A dedicated interactive prompt when codex is about to perform an action the current mode disallows: "This action requires workspace-write. Elevate for this action / for the rest of the session / cancel?"
3. A CLI subcommand that mutates a running session by session id, e.g. codex session set-sandbox <id> workspace-write.

Option 1 is the most ergonomic. Option 2 is the safest default because escalation is scoped and explicit.

Why not just restart?

• Loses conversation history and reasoning traces (thread.started id changes)
• Loses any resumed session state (codex exec resume <id> re-hydrates from disk but is not the same as an unbroken interactive session)
• Interrupts flow — the user has to remember what they were about to do
• Encourages users to just start in the most permissive mode "to avoid restarts," which is the opposite of what the sandbox is for

Environment

• codex-cli version: 0.144.1
• OS: macOS (Darwin 25.4)
• Auth: codex login

Related

Anything that touches the approval policy / sandbox model is relevant here. Happy to prototype a /sandbox slash command if maintainers can point me at where the approval policy is enforced at the loop level

Additional information

_No response_