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

[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
     }
   }

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.

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.

I'm seeing the behavior @enomado describes, but in addition, when the sandbox is used in the TUI, it asks for permissions for non-allow listed domains, this prompt doesn't appear in VS Code, the request is just blocked automatically.