VS Code extension ignores sandbox settings.json / /sandbox unavailable (approval-fatigue fix unreachable in IDE)

[enomado]

What happened

When using Claude Code via the VS Code extension (v2.1.156), the Bash sandbox configured in settings.json is never activated:

• A valid sandbox block in .claude/settings.local.json (or ~/.claude/settings.json) with "enabled": true and "autoAllowBashIfSandboxed": true is silently ignored — Bash commands continue to go through the normal permission flow and prompt as if no sandbox were configured.
• The /sandbox slash command does not exist in the extension — typing it returns "No matching commands".

The docs (https://code.claude.com/docs/en/sandboxing) describe /sandbox and sandbox.enabled as the way to turn this on, with no mention that the IDE extension is excluded. The same config works as expected when running claude --sandbox from a terminal.

Why this matters (approval fatigue)

The sandbox is the documented remedy for permission-prompt approval fatigue (Anthropic cites ~84% fewer prompts). Allowlists structurally cannot cover the long tail of harmless commands — command substitution $(...), compound a && b gated by the least-privileged segment, and one-off novel commands all still prompt no matter how complete the allowlist is. For extension users that long tail is currently unfixable, because the one mechanism that would fix it can't be turned on.

Background

This was previously reported and closed-as-duplicate, with the chain ending in issues that are now closed and locked, and were macOS-flavored:

• VS Code/Cursor extension should pass --sandbox flag when sandbox is enabled in settings.json #32814 → duplicate of Sandbox cannot be enabled on macOS: /sandbox menu unresponsive and settings.json ignored #32416 (both CLOSED, locked)

The auto-close bot's message on those explicitly says "please file a new issue." I could not find any open issue tracking specifically "the IDE extension does not pass --sandbox / does not activate the sandbox from settings.json", so filing fresh.

Expected behavior

The VS Code (and Cursor/JetBrains) extension should honor sandbox.enabled from settings.json — i.e. spawn the underlying Claude Code process with sandboxing active (equivalent to --sandbox) — so that autoAllowBashIfSandboxed works and /sandbox (or an equivalent settings-driven activation) is available in the IDE, matching the terminal CLI and the documentation.

Environment

• Claude Code: 2.1.156
• Surface: VS Code native extension
• OS: Linux (Arch), kernel 7.0.x
• Sandbox deps present: bubblewrap 0.11.2, socat; no AppArmor unprivileged-userns restriction
• claude --sandbox from a terminal works correctly with the same settings.json

Repro

1. In the VS Code extension, add a valid sandbox block with "enabled": true to .claude/settings.local.json.
2. Restart the extension / reload the window.
3. Ask Claude to run a non-allowlisted Bash command (e.g. something using $(...)).
4. Observe: it still prompts for permission; /sandbox returns "No matching commands".

[deyjayprakash123-cloud]

[BUG] IDE Extension fails to pass --sandbox flag / ignores sandbox.enabled in settings.json

Summary

When using Claude Code via the VS Code / Cursor extension, the Bash sandbox configuration is never activated. Even with a valid sandbox block set to "enabled": true and "autoAllowBashIfSandboxed": true in settings.json (or settings.local.json), the extension spawns the underlying native binary wrapper without the --sandbox process flag. As a result, Bash commands continue to trigger manual permission prompts, causing immense approval fatigue.

Additionally, the /sandbox slash command is completely missing inside the extension ("No matching commands"). The identical configuration works perfectly when running claude --sandbox directly from a standard system terminal.

Current Behavior

1. The extension parses settings.json via --setting-sources, but the process spawner ignores the sandbox.enabled boolean.
2. The core agent is spawned without bubblewrap (Linux) or Seatbelt (macOS) constraints.
3. Every non-allowlisted command, compound command (&&), or command substitution ($(...)) triggers an approval prompt.
4. The /sandbox command is unavailable in the IDE chat UI.

Expected Behavior

The VS Code extension should inspect the computed settings lifecycle during process initialization. If sandbox.enabled: true is present, it must append the --sandbox flag to the spawned execution command so that the Linux bubblewrap namespace / socket proxies are stood up correctly, enabling autoAllowBashIfSandboxed to function as documented.

Why This Matters (Approval Fatigue)

As cited in Anthropic documentation, sandboxing reduces permission prompts by ~84%. Static allowlists structurally cannot account for the long tail of complex developer commands (e.g., recursive operations, dynamically evaluated variables, or compound pipes). For IDE extension users, this makes the tool significantly more frustrating to use than its terminal counterpart.

Environment

• Claude Code Version: 2.1.156
• Surface: VS Code Native Extension (also impacts Cursor)
• OS: Linux (Arch), kernel 7.0.x (Confirmed also on macOS Darwin)
• Sandbox Dependencies: bubblewrap 0.11.2, socat present and functional.

Steps to Reproduce

1. In the VS Code environment, add the following to .claude/settings.local.json:

   {
     "sandbox": {
       "enabled": true,
       "autoAllowBashIfSandboxed": true
     }
   }

[enomado]

This is a regression, not a feature request — last-good version is known

Adding context that reframes this and should make it cheaper to fix.

#31865 ([BUG] autoAllowBashIfSandboxed regression in v2.1.70+ VSCode extension — write commands prompt despite sandbox) reports that this exact behavior worked in the extension in v2.1.68 and broke in v2.1.70:

autoAllowBashIfSandboxed: true stopped working for Bash write commands in the VSCode extension starting with v2.1.70. […] Downgrading to v2.1.68 restores correct behavior.

That issue was not closed as "won't fix" or "by design" — it was auto-closed by the bot for inactivity (NOT_PLANNED, "Closing for now — inactive for too long"), with no maintainer ever responding, and is now locked. So the capability is not something that "was never supported in the IDE" — it demonstrably shipped and worked, then regressed and the report quietly aged out.

So the ask here is "restore v2.1.68 behavior", not "build something new":

• Known-good: v2.1.68 (extension honored autoAllowBashIfSandboxed)
• First-bad: v2.1.70
• Still broken: v2.1.156 (current)

For what it's worth, the sandbox area has had fixes land recently — e.g. #31804 (macOS sandbox prerequisites) was closed COMPLETED — so this isn't an untouched subsystem; the extension-side activation path just seems to have been missed by that work.

Could this be re-triaged as a regression and pinned to a milestone rather than left to auto-close? Happy to provide extension logs or a git-bisect-style confirmation across v2.1.68 → v2.1.70 if that helps narrow the spawn-flag change.

[enomado]

Narrowing the bug: the sandbox runtime is active in the extension — it's autoAllowBashIfSandboxed that isn't wired to it

Correcting/sharpening my own report. The problem is not "the extension never starts the sandbox." It does. The problem is that auto-allow is not applied on top of the running sandbox.

Evidence from inside a Bash tool call in the VS Code extension (entrypoint claude-vscode, v2.1.156, Linux):

SANDBOX_RUNTIME=1
CLAUDE_CODE_HOST_HTTP_PROXY_PORT=46007
CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=45127
CLAUDE_CODE_ENTRYPOINT=claude-vscode

So the sandbox runtime is up and the network proxy is live. Confirmed empirically:

• Network isolation is enforced: curl https://registry.npmjs.org/ fails with CONNECT tunnel failed, response 403 — the proxy is rejecting non-allowlisted domains exactly as designed.
• Filesystem boundary is in effect (writes constrained to the configured allow-write set).

…and yet, with this in .claude/settings.local.json:

{ "sandbox": { "enabled": true, "autoAllowBashIfSandboxed": true } }

Bash commands still hit manual permission prompts — $(...) substitutions, compound a && b, and any non-allowlisted command all prompt, despite the sandbox demonstrably running. So autoAllowBashIfSandboxed: true is being ignored even though the very condition it gates on (commands running inside the sandbox) is satisfied.

/sandbox behavior

In this extension build, /sandbox now returns "/sandbox isn't available in this environment" (previously "No matching commands"). Consistent with the runtime being managed by the environment rather than the in-app panel — but it leaves users with no UI to toggle auto-allow, and the settings.json key doesn't take effect either.

Net

This lines up with the #31865 regression (worked v2.1.68 → broke v2.1.70). The narrowed ask: in the extension, when SANDBOX_RUNTIME is active, honor autoAllowBashIfSandboxed so sandboxed Bash auto-approves — i.e. reconnect the auto-allow path to the already-running sandbox, rather than (re)starting anything.

Happy to capture extension logs around a prompted command if the proxy/auto-allow handoff is logged.