Sandbox can refuse SOCKS and other non-HTTPS tunnels it cannot inspect

What

The sandbox limits what commands Claude runs can reach on your machine and on the network. Its network side includes a proxy that looks inside encrypted HTTPS traffic (TLS is the encryption HTTPS uses). A tunnel is a connection the proxy passes along without reading it. The sandbox can now refuse tunnels it cannot inspect:

• The TLS-inspecting proxy can refuse a CONNECT tunnel (a request to open a raw connection through the proxy) that carries non-TLS bytes. This happens when a new refuseUninspectedTunnel hook returns true. The connection is closed and logged with the message "non-TLS bytes on CONNECT". Before, the proxy always let such traffic through as an opaque tunnel.
• The sandbox network filter gains a check, applied when filterRequest is configured, that refuses SOCKS and other non-HTTPS tunnels to hosts that require inspection. Before, the filter only checked denied and allowed domains and strictAllowlist.
• If the settings do not say which hosts need inspection, all such tunnels are blocked.
• The sandbox config update now carries network.denyUninspectedTunnel through alongside filterRequest. Before, only filterRequest was kept.

The refusal tells Claude: "this host can only be reached over HTTPS through the sandbox's HTTP proxy; SOCKS and other non-HTTPS connections to it are blocked. Do NOT retry with dangerouslyDisableSandbox."

Why

Sandboxed commands that used SOCKS or plain connections to reach hosts the sandbox needs to inspect can now fail where they used to work. The fix is to reach those hosts over HTTPS through the sandbox's proxy, and Claude is told not to get around the block by running the command outside the sandbox with dangerouslyDisableSandbox.