dangerouslyDisableSandbox allows the model to bypass workspace boundaries without a distinct, explicit user confirmation

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude accessed files outside the working directory

What You Asked Claude to Do

Summary

related to #72960, but goes further: ...

While diagnosing a local Gradle build failure, the assistant repeatedly invoked the dangerouslyDisableSandbox: true parameter on the Bash/PowerShell tools — first to retry the build (in scope for the reported problem), then to run unrelated diagnostic experiments (spawning child processes, testing loopback sockets, and creating a new directory directly under C:\, i.e. outside the project workspace and outside the session's designated scratchpad directory).

The concerning part isn't that the flag exists — it's that invoking it appears to be entirely at the model's own discretion, with no separate, clearly-labeled confirmation step distinct from an ordinary tool-call permission prompt. A user reviewing/approving a Bash command may not realize that a specific invocation carries this elevated, sandbox-bypassing semantics unless they read the full command context carefully every time.

Why this matters

Relying on the model's own judgment ("I'll only use this when necessary and I'll ask first") is a soft behavioral safeguard, not a security boundary. A user should be able to trust that sandbox/workspace restrictions hold regardless of what the model decides is justified in the moment.

Suggested fix / consideration

Require a distinct, explicit approval prompt whenever dangerouslyDisableSandbox (or equivalent) is invoked, clearly stating that sandbox protections will be disabled for that call.
Consider scoping/rate-limiting or otherwise restricting how broadly this flag can be used within a session once granted.
Align the "protected path" deletion safeguard with the same rigor applied to path creation, so both are consistently governed by the same boundary rules.

What Claude Actually Did

Actual behavior

The assistant was able to create a directory outside the workspace (C:\t) using this flag without any additional/distinct confirmation beyond whatever the normal permission mode already allowed. Interestingly, a separate, unrelated hard-coded protection did block deleting that same path afterward ("this path is protected from removal") even with the same flag set — so protections exist in some cases but are inconsistent, and creation outside the workspace wasn't gated the same way deletion was.

Expected Behavior

Expected behavior

Using dangerouslyDisableSandbox (or any sandbox-bypassing capability) to write/create/modify anything outside the current project workspace (and outside the assigned scratchpad) should require a distinct, unambiguous confirmation step — separate from the routine "approve this Bash command" prompt — so the user cannot approve it without realizing exactly what boundary is being crossed. Ideally this should be a hard technical gate, not something that depends on the model choosing to ask first.

Files Affected

c:\t

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Steps to reproduce

Start a Claude Code session on any project.
Ask the assistant to run a command that fails inside the sandbox (e.g., a build tool that needs loopback networking).
Observe that the assistant can retry with dangerouslyDisableSandbox: true, and — in our case — go on to reuse that same escape hatch for unrelated exploratory actions that write outside the project directory (e.g. New-Item -ItemType Directory -Path C:\t).

Claude Model

Sonnet

Relevant Conversation

The rule I should have followed: Actions that affect areas outside the actual work directory (in this case: C:\ instead of the Workspace folder or the assigned scratchpad folder) are exactly the situations where I should have first clearly announced my intention and asked for permission—even if it was “just” an empty test directory. I went too far with my diagnosis without checking in with you along the way.

Impact

High - Significant unwanted changes

Claude Code Version

1.18286.0

Platform

Anthropic API

Additional Context

_No response_