Quick Answer
Anthropic’s sandbox-runtime fixes a Windows network-filter matching gap affecting AppContainer processes running under its sandbox account. The merged change adds package SID grants to the descriptor used by the Windows Filtering Platform BLOCK filter. That lets the intended AppContainer token satisfy the access check that makes the block apply.
The v0.0.81 release, published October 20, identifies its changes as Windows-only. It also introduces optional loopback access and more detailed verification results. These changes close one matching gap and expose remaining limits; a successful verifier result still does not establish complete network isolation.
In Plain English
A blocking rule helps only when it recognizes the connection it should block. Here, recognition involves a Windows access check against the connecting token. Before this patch, the descriptor named the sandbox account, but an AppContainer token for that account also needed a package grant. Without it, the account grant alone did not make the BLOCK filter match.
The merged commit preserves the account grant and adds the missing package grants. The intended before-and-after behavior is specific: an AppContainer process belonging to the sandbox account now matches the block. The account boundary remains relevant, so adding package grants does not make another account’s AppContainer token match.
Code Evidence
In wfp.rs, the descriptor gains entries for S-1-15-2-1 and S-1-15-2-2. The important distinction is that these grants participate in deciding whether the BLOCK applies. An allow entry inside this matching descriptor is therefore not permission to send network traffic.
The AccessCheck matrix captures three expectations: the revised descriptor matches the account’s AppContainer token, the previous account-only descriptor does not, and a descriptor naming another account does not. This tests descriptor semantics directly, without a live WFP engine. Its lowered-integrity row also records a mapping-dependent result rather than asserting an unsupported universal outcome.
The expanded probe implementation distinguishes plain, anonymous, deny-only, low-integrity, and untrusted-integrity outcomes. For assumed identities, it checks both socket-creation orderings because attribution depends on the token effective when the socket was created. It also confirms the intended thread token before measuring the connection.
Both connected and connection-refused outcomes mean the attempt passed the filters: a destination rejecting a connection is different from WFP blocking it. Plain or lowered-integrity attempts that pass fail verification. A lowered-integrity token that cannot be prepared becomes an explicit unprobed residual, rather than evidence of blocking.
Why It Matters
For application developers, the other consequential change is loopback configuration. Previously, the installed filter set permitted loopback only within the proxy port range. The new opt-in mode adds a loopback PERMIT at each IPv4 and IPv6 connect layer. Its range is 2–65535; port 1 remains reserved for checking the fence, and port 0 is outside that added permit.
The Windows CLI exposes the installation choice through --allow-loopback. It remains off by default. Opening it makes TCP and UDP listeners on 127.0.0.0/8 and ::1 reachable under the intended account-token behavior. That includes local forwarders whose onward traffic is outside the domain allowlist.
This is a machine-wide choice, even though applications express it through session configuration. The session manager rejects a mismatch with wfp_loopback_mismatch; native execution uses exit 19 and launches nothing. Commands requesting another mode are refused until reset and initialization use a matching installation. Applications sharing that installation therefore need a consistent setting.
An Open Question
Should an application continue after the verifier reports anonymous-token or deny-only-token residuals as warnings, or should its policy require a stricter boundary?
The TypeScript verifier wrapper returns named residuals and warning text. Those residuals do not themselves reject an otherwise passing verification. Resolving the application-level question requires a documented threat model explaining which residuals are acceptable, supported by tests showing the chosen behavior when each appears. The library’s warning policy cannot supply that product decision by itself.
Scope and Limitations
The supplied research inspected test and smoke-script source; it executed no tests, CI jobs, or live network probes. The Windows integration test source covers verifier verdicts, residual warnings, configuration mismatches, and proxy environment behavior. That documents intended coverage without independently establishing runtime success.
Normal initialization omits the optional off-loopback anonymous probe, which can take seconds. With loopback closed, anonymous-loopback and deny-only observations remain part of the normal probe. Missing off-loopback targets and unsuccessful lowered-token setup limit what was measured; they must not be interpreted as observed blocks.
The updated README also documents service-carried traffic, including SMB and WSL-related limits, and token-derived cases outside the account-keyed fence. The supplied tests do not establish exhaustive coverage of every possible token derivation. Developers should assess these boundaries alongside the AppContainer fix before relying on the filter for their application’s isolation requirements.
Sources
Checked October 22, 2026.