Sandbox network domain filter silently fails open after in-session sandbox settings changes

Environment

• Claude Code v2.1.212
• macOS (Darwin 25.5.0), Seatbelt sandbox
• sandbox.enabled: true, autoAllowBashIfSandboxed (default), network.allowedDomains set (no wildcard-all), allowLocalBinding: true

Summary

The sandbox network proxy (srt, localhost auth proxy) enforces network.allowedDomains correctly at session start, but after editing unrelated sandbox settings (sandbox.filesystem.allowWrite, sandbox.network.allowMachLookup) in ~/.claude/settings.json while the session is running, the same proxy process (same port) stops enforcing the domain filter entirely. It then accepts CONNECT requests to domains that are not on the allowlist and returns real content. Reverting the settings edits does not restore enforcement; only a session restart does.

This is a silent fail-open of a security boundary: no error, no warning, and the session continues to look sandboxed.

Steps to reproduce

1. Enable the sandbox with a restrictive network.allowedDomains (e.g. only gitlab.com), start a fresh session.
2. In the session, run curl -s -o /dev/null -w "%{http_code}" https://example.com → blocked as expected (000, proxy refuses; https://gitlab.com works).
3. While the session is running, edit ~/.claude/settings.json: add sandbox.filesystem.allowWrite entries and/or sandbox.network.allowMachLookup. (These hot-reload correctly: the new write paths become writable immediately.)
4. Run the same curl again.

Observed

• curl -v https://example.com now shows CONNECT example.com:443 answered with HTTP/1.1 200 Connection Established by the sandbox proxy (same HTTPS_PROXY port as before the edit), and the real upstream response comes back (200, genuine Cloudflare headers).
• Removing the settings edits again (full revert to the config that enforced the filter at session start) does not close the filter; it stays open for the rest of the session.
• Filesystem rules meanwhile hot-reload correctly in both directions (adding an allowWrite path takes effect immediately, removing it blocks writes again immediately), so the config reload mechanism itself is clearly active.

Expected

Either the network filter keeps enforcing the current (or the session-start) allowedDomains after a settings reload, or - if the proxy cannot re-apply the network config - the sandbox should fail closed / warn, not silently allow all domains.

Notes

• Reproduced twice on two consecutive days (first noticed right after activating the sandbox mid-session; confirmed today in a fresh session that enforced the filter for the first ~2 hours until the first sandbox settings edit).
• Possibly related docs nit found while debugging: bare command names in sandbox.excludedCommands (e.g. "git") match nothing in practice; only the documented wildcard form ("git *") works. If bare names are indeed unsupported, a validation warning would help.