{"version":"2.1.304","anchor":"sandbox-proxy-gains-request-filter-hardening-options","canonical_anchor":"sandbox-proxy-gains-request-filter-hardening-options","heading":"Sandbox hardening: stricter network proxy checks and credential files that stay closed","tier":"use","area":"Sandbox","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304\/e\/sandbox-proxy-gains-request-filter-hardening-options","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304","markdown":"### Sandbox hardening: stricter network proxy checks and credential files that stay closed\n\nThe sandbox proxy now checks request targets, Host and SNI, and credential-file denies can no longer be reopened by broader allows\n\n**Unclear.** Whether Claude Code itself sets any of these options is not stated.\n\n**What**\n\nThe sandbox is the protected space where Claude Code runs commands with limited access to your files and network. This release tightens it:\n\n- Credential files: denies on credential files are now kept separately (`credentialDenies`), so a broader `allowRead` or `allowWrite` entry no longer reopens them. On Windows, an allow beneath a credential entry is warned about and \"not granted\". A `denyWrite` entry makes an overlapping allow read-only.\n\n- Request checks: the network proxy now parses each request's target and answers 400 to ambiguous or malformed ones. It requires a Host header on HTTP\/1.1 (\"HTTP\/1.1 request without a Host header\"). With `requireHostMatch` it answers 421 when the Host header does not match the site named when the encrypted connection was set up (SNI). Some HTTP methods are refused with 405 and \"the ${method} method is not forwarded\".\n\n- Filter decisions: the request filter now receives SNI and target details, and its answer is validated (\"malformed filterRequest decision: ${J}\"). It can add a deny header and strip response headers, and setting headers on plaintext requests is denied. A network ask callback that returns anything other than true or false or `{ allow: false, reason }` is treated as a denial, and deny reasons can be passed on to a callback.\n\n- New proxy options: `allowPlaintextHeaderSet`, `stripResponseHeaders`, `refuseOpaqueTunnels` (also on the SOCKS proxy), `requireHostMatch`, `ambiguousRequestTarget` (default \"refuse\", applied only while `filterRequest` is set), `tlsTerminate.maxTunnels` (default 256) and `handshakeTimeoutMs` (default 10000). They are optional, so nothing changes unless a program embedding the sandbox sets them.\n\n- Failures from the far server after a whole answer has arrived are logged instead of reported.\n\n- On Linux, the socat bridge now listens on IPv6 with an IPv4 fallback and `backlog=4096`.\n\n- bwrap errors about too many arguments now explain that built-in write protection takes most of them.\n\n**Why**\n\nCredential files stay protected even when a broad allow rule covers their folder, and the proxy can refuse requests that disguise where they are going. If you relied on an allow rule to reach a file under a credential entry, it no longer opens it.\n\n- Area: Sandbox\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5\n- Scope: both\n- Heads-up: yes"}