Feature request: per-host SSH/TCP allowlist in sandbox network config

Problem

The sandbox network filter is an HTTP/HTTPS proxy, which means allowedDomains only controls which hostnames the proxy forwards HTTP/HTTPS traffic to. SSH (port 22) and other raw TCP connections cannot traverse the proxy at all, regardless of whether the host is in allowedDomains.

This creates a counterintuitive situation: the only way to allow SSH connections to specific, trusted hosts is to disable sandbox protection entirely (via excludedCommands or allowUnsandboxedCommands), which removes all network and filesystem restrictions for those commands.

In other words, to use a secure protocol (SSH), you must run insecure (unsandboxed).

Current workarounds

Users who need to SSH to build machines, test machines, or deployment servers on their local network are forced to either:

1. Build custom HTTP MCP servers on every remote machine as an SSH replacement — significant engineering overhead per host
2. Use excludedCommands — removes ALL sandbox restrictions for that command, not just network
3. Disable the sandbox entirely — loses all protection
4. Avoid Claude Code for SSH tasks — defeats the purpose

Proposed solution

Add protocol-aware, per-host, per-port network rules to the sandbox configuration:

{
  "sandbox": {
    "network": {
      "allowedDomains": ["github.com", "api.github.com", "*.npmjs.org"],
      "allowedConnections": [
        { "host": "github.com", "port": 22 },
        { "host": "192.168.1.100", "port": [22, 3000] },
        { "host": "my-build-server.local", "port": 22 }
      ]
    }
  }
}

Where allowedDomains continues to handle HTTP/HTTPS traffic via the existing proxy, and allowedConnections handles raw TCP connections (SSH, custom TCP services) via a network namespace, iptables/nftables rules, or similar mechanism.

Use cases

• Git push via SSH — Many developers use SSH remotes with per-key host aliases in ~/.ssh/config. Switching every repo to HTTPS is a workaround, not a solution.
• Remote build machines — SSH to build servers for cross-compilation (e.g., building macOS binaries on a Mac from a Linux dev machine).
• Remote test machines — SSH to test machines for deployment verification and diagnostics.
• Deployment servers — SSH to production/staging hosts for deploys (e.g., cPanel, bare-metal servers).
• Multi-machine development — Teams working across LAN machines for distributed builds, testing, or task delegation.

Why this matters

The current proxy-only architecture forces an all-or-nothing choice between sandbox protection and SSH access. Many real-world development workflows depend on SSH to a small, known set of hosts. A per-host TCP allowlist would preserve the sandbox's security guarantees while supporting these workflows — the same way allowedDomains already does for HTTP/HTTPS.