[FEATURE] Let a user-approved, task-scoped sandbox exception take effect in the running session

Problem Statement
We run Claude Code in auto mode with the sandbox on, and it works well for most work. Some approved tasks need one command to run outside the sandbox, for example a script that queries a production database, or a cloud CLI that has to reach its API. The user approves the task and names exactly which command may run unsandboxed.

Today there is no way to apply that approval to the running session:

• /sandbox exclude is refused when the sandbox comes from --settings (separate bug report).
• If the model or a hook adds the pattern to excludedCommands in user settings mid-session, the auto mode classifier refuses the write, labelled "Auto-Mode Bypass" or "Security Weaken". That is a reasonable refusal, because the model is widening its own sandbox.
• The only path that works is to restart with the exception in the launch settings and --resume the session. Our wrapper now does this automatically: it runs claude as a child process, ends it with SIGTERM from a Stop hook, and relaunches it with --resume <id> "<prompt>".

Once the exception is in the launch settings, the classifier lets the approved command run (observed with a production SQL script). The approval model works; the missing piece is applying it without a restart.

Proposed Solution
A user-side action that adds an exception to the running session, visibly and only from user input. The model could not trigger it. For example:

• /sandbox allow-once <pattern>, lasting until the session ends; or
• a permission prompt shown when a command fails with a sandbox error: "Run <pattern> outside the sandbox for this session?"

Either should work regardless of which settings tier configured the sandbox.

Alternative Solutions
A supported "restart and resume me" path: a hook return value that asks the CLI to exit cleanly and reopen the same session with re-read settings.

Priority: Medium
Feature Category: Configuration

Use Case Example
The user confirms a task whose plan says "runs scripts/prod-sql * outside the sandbox". The confirmation grants exactly that pattern until the task is done. The model runs the script, and everything else stays sandboxed.