excludedCommands does not bypass network sandbox for SSH/git operations

Description

excludedCommands in sandbox settings does not fully bypass the network sandbox. Commands listed in excludedCommands are expected to run completely outside the sandbox, but they still have network restrictions applied — specifically, SSH connections fail even when the target host is in allowedNetworkHosts.

Steps to reproduce

1. Configure sandbox settings in ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker", "git"],
    "allowedNetworkHosts": ["github.com", "api.github.com"]
  }
}

1. Start a new Claude Code session

1. Run any git command that uses SSH:

git push origin my-branch -u
git ls-remote --heads git@github.com:owner/repo.git

1. Observe DNS resolution failure:

ssh: Could not resolve hostname github.com: Temporary failure in name resolution
fatal: Could not read from remote repository.

1. Same command with dangerouslyDisableSandbox: true works fine.

Expected behavior

Commands listed in excludedCommands should bypass all sandbox restrictions, including network/DNS filtering. This is consistent with how docker exclusion is documented to work.

Actual behavior

• excludedCommands appears to bypass filesystem restrictions (e.g., chezmoi can write to its state DB when excluded)
• excludedCommands does not bypass network restrictions — SSH connections still fail because DNS resolution to 127.0.0.53 (systemd-resolved) is blocked
• allowedNetworkHosts only covers HTTP/HTTPS connections, not SSH (port 22)
• The only workaround is dangerouslyDisableSandbox: true

Additional context

• The runtime sandbox Network: {"allowedHosts": [...]} does include github.com
• git is confirmed in excludedCommands via settings.json
• The session was freshly started (not resumed) after settings were deployed
• Platform: Linux (systemd-resolved for DNS on 127.0.0.53)