[FEATURE] Monitor needs to respect `sandbox.excludedCommands` and have a `dangerouslyDisableSandbox` option

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Monitor tool cannot be run outside the sandbox, which makes it unusable for monitoring commands that require host access. Specifically:

• Bash accepts a dangerouslyDisableSandbox parameter and honors sandbox.excludedCommands from settings.json. Monitor honors neither — there is no

per-call escape hatch and no way to allowlist a command.

• Concrete use case: I want a Monitor that tails GCP logs via gcloud logging read / gcloud beta run services logs tail. gcloud only authenticates

correctly when run outside the sandbox (I have it in excludedCommands for exactly this reason, and it works fine via Bash).

• The result is that any "watch this stream" workflow that depends on host auth, host networking, or a credential helper has to be done with Bash

run_in_background polling instead of Monitor, which defeats the purpose of the tool.

Proposed Solution

Bring Monitor to parity with Bash for sandbox handling:

1. Accept a dangerouslyDisableSandbox: true parameter on Monitor calls, with the same approval/prompting UX as Bash.
2. Honor sandbox.excludedCommands from settings.json — if the monitored command matches the allowlist, run it outside the sandbox automatically (same

matching rules as Bash).

1. Document this in the Monitor tool description so the model knows it's an option (currently the tool docs don't mention sandboxing at all).

Alternative Solutions

• Bash with run_in_background + polling — works, but loses Monitor's streaming/notification semantics; I have to read the log file periodically instead of reacting to new lines, and it eats more context.
• Piping gcloud output to a file from a sandbox-disabled Bash call, then Monitor-ing the file — fragile (auth refresh, partial writes, file rotation)

and adds a moving part for something that should be one call.

• Running claude itself with the sandbox disabled globally — overkill and removes the safety I want for everything else.
• Skipping Monitor entirely and using a separate terminal with gcloud ... tail — works but defeats the point of having Claude watch the stream

Priority

Low - Nice to have

Feature Category

Interactive mode (TUI)

Use Case Example

1. I add gcloud to sandbox.excludedCommands in settings.json so it can authenticate against GCP.
2. Running gcloud logging read ... via Bash works — the excludedCommands rule kicks in and the command runs outside the sandbox with valid credentials.
3. I try to set up a Monitor on gcloud beta run services logs tail my-service to watch a Cloud Run service while I work.
4. Monitor runs the command inside the sandbox anyway, ignoring excludedCommands, so gcloud fails to authenticate and the monitor produces no useful

output.

1. There is no dangerouslyDisableSandbox parameter on Monitor to force it out of the sandbox per-call either, so I have no escape hatch.
2. I fall back to Bash run_in_background + polling a log file, which loses Monitor's streaming/notification semantics.

Additional Context

_No response_