sandbox.excludedCommands has no effect: listed commands still run sandboxed

Summary

sandbox.excludedCommands has no effect: commands listed there still run inside the sandbox and fail on sandbox restrictions. Measured on macOS 24.6.0 (Darwin), Claude Code with a managed sandbox block.

Configuration

/Library/Application Support/ClaudeCode/managed-settings.json:

"sandbox": {
  "enabled": true,
  "failIfUnavailable": true,
  "autoAllowBashIfSandboxed": true,
  "excludedCommands": ["segreti *", "docker *", "gh *", "gh-axi *", "glab *", "glab-axi *",
                       "voicebox *", "ps *", "pgrep *", "sudo *", "su *",
                       "brew install *", "brew upgrade *", "brew uninstall *",
                       "brew reinstall *", "brew services *"],
  "network": { "allowedDomains": ["*"], "allowAllUnixSockets": true, "allowLocalBinding": true }
}

Observed

Each command below is in excludedCommands and was run alone on its line through the Bash tool:

| Command | Result |
| --- | --- |
| ps -p 1 | operation not permitted: ps |
| pgrep -x node | sysmon request failed with error: sysmond service not found / pgrep: Cannot get process list |
| gh pr view <n> --repo <owner>/<repo> --json state | Post "https://api.github.com/graphql": tls: failed to verify certificate: x509: OSStatus -26276 |

The same ps -p 1, re-run with dangerouslyDisableSandbox: true, succeeds and prints 1 /sbin/launchd. So the command works unsandboxed — the exclusion list simply is not applied.

The gh failure is the same cause wearing a misleading message: curl https://api.github.com/ from the same shell returns 200 and verifies the real certificate chain, so it is not a TLS or proxy problem — the Go binary cannot reach the system trust service, exactly as pgrep cannot reach sysmond.

Not caused by allowUnsandboxedCommands

The same block also had "allowUnsandboxedCommands": false. Removing that key and restarting changed nothing for the three commands above — identical failures before and after. It only restored the model's ability to request dangerouslyDisableSandbox, which is what the documentation says it governs.

Expected

Per the settings reference and the SDK type docs, excludedCommands are "commands that always bypass sandbox restrictions ... These run unsandboxed automatically without model involvement", and allowUnsandboxedCommands is documented as independent of it.

Either the exclusion list is not being applied, or its documented behaviour differs from the implementation. As it stands, every exempted command costs an interactive permission prompt, which is the opposite of the feature's purpose.

Question

Is the pattern syntax the issue? Both ["docker *"] (settings-reference JSON example) and ['docker'] (SDK type description) appear in the docs. The entries above use the "<cmd> *" form and were invoked with arguments.