claude-code - 💡(How to fix) Fix [BUG] `excludedCommands` entries with `:*` suffix silently disable the entire sandbox for all Bash calls [1 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Adding an entry with a :* suffix to sandbox.excludedCommands — the community workaround widely celebrated in #10524 to fix the "exact match only" pattern problem — disables the entire sandbox for all subsequent Bash tool calls, not just the matched command.

This is a silent security regression. /sandbox still reports the sandbox as enabled, proxy env vars disappear from Bash calls, and writes to non-allowlisted paths succeed. Users following the top-voted comment in #10524 ("uv:*", 29 👍, 8 hooray, 11 heart) believe their sandbox is active while it is in fact entirely off.

Reproduction

Starting ~/.claude/settings.json:

"sandbox": {
  "enabled": true,
  "autoAllowBashIfSandboxed": true,
  "excludedCommands": ["linear"]
}

State A — "linear" (no :*), baseline

Run Bash tool calls:

$ env | grep -i proxy | head -3
HTTP_PROXY=http://localhost:63682
HTTPS_PROXY=http://localhost:63682
ALL_PROXY=socks5h://localhost:63683

$ touch /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test
touch: /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test: Operation not permitted

Sandbox is active: proxy env vars injected, write to a non-allowlisted path is blocked.

State B — edit to "linear:*" (the community workaround)

Change the entry from "linear" to "linear:*". No other edits. Run Bash calls again:

$ env | grep -i proxy | head -3
(empty — all proxy env vars gone)

$ touch /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test
(succeeds)

$ ls /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test
-rw-r--r--  1 user  staff  0 Apr  8 11:12 sandbox-test

Sandbox is effectively off. Critically, the env command does not match the linear:* pattern at all, yet it runs in an unsandboxed shell. Every subsequent Bash call is unsandboxed.

State C — revert to "linear"

Change back to the original. Next Bash call:

$ env | grep -i proxy | head -3
HTTP_PROXY=http://localhost:63682
HTTPS_PROXY=http://localhost:63682
ALL_PROXY=socks5h://localhost:63683

$ touch /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test
touch: /Users/vit/Documents/works/SomePathNotInAllowlist/sandbox-test: Operation not permitted

Sandbox is restored. The behavior is deterministic and fully reversible. Reproduced under both "auto" and "standard" sandbox modes (/sandbox toggling between the two).

What Should Happen?

One of:

• (a) Parse "linear:*" correctly so it matches only linear <anything> and does not affect other commands. The sandbox should remain active for all non-matching calls.
• (b) If the :* syntax is not supported in excludedCommands (only in Bash(...) permission patterns), reject malformed entries at load time with a clear error. Do not silently disable the sandbox.

Either way, /sandbox should not report the sandbox as enabled when it is, in effect, entirely off.

Related issues

• #10524 — excludedCommands does exact match and requires :* to work with arguments. Currently open. The top-voted workaround there is what triggers this regression.
• #12150 — excludedCommands leaks proxy env vars into child processes. Auto-closed for inactivity without a fix. Relevant because even a correctly-working excludedCommands still inherits proxy env vars, which breaks Deno-compiled CLIs that honor ALL_PROXY but cannot use SOCKS schemes via env vars.

Error Messages/Logs

No errors. The sandbox silently deactivates. /sandbox continues to report "Sandbox enabled" during the regression, which is the most concerning aspect — there is no user-facing indication that anything is wrong.

Steps to Reproduce

1. In ~/.claude/settings.json, set sandbox.enabled: true and add an excludedCommands entry without :*, e.g. "linear".
2. Start a Claude Code session. Run a Bash tool call with env | grep -i proxy and touch on a path outside the allowlist. Verify sandbox is active.
3. Edit the entry to "linear:*" (the top-voted community workaround from #10524). Save.
4. Run another Bash tool call with the same commands.
5. Observe that proxy env vars are empty and the touch succeeds. The sandbox is effectively off for all Bash calls, not only ones matching linear:*.
6. Revert to "linear". Sandbox returns to active state on next call.

Claude Model

Opus (custom / 1M context)

Is this a regression?

I don't know — this requires the :* community workaround, which gained traction in #10524 comments through Nov 2025. Users may have been unknowingly running without a sandbox for months.

Last Working Version

No response

Claude Code Version

2.1.96 (Claude Code)

Platform

Anthropic API

Operating System

macOS 26.1 (arm64)

Terminal/Shell

zsh 5.9

Additional Information

The original scenario that led me to the :* workaround was a deno compile CLI (@schpet/linear-cli) failing in the sandbox because Deno's fetch honors ALL_PROXY=socks5h://... but cannot use SOCKS schemes via env vars (denoland/deno discussion#17606), while Go-based tools like gh silently worked because Go's net/http ignores ALL_PROXY. Either fixing this :* regression or scrubbing proxy env vars when spawning excluded commands would resolve both problems. The latter (proxy env scrubbing) is already requested in #12150.

I've worked around the original CLI problem with a local wrapper script, but the sandbox disable regression is independent of that scenario and would affect any user who followed the #10524 workaround.