The sandbox network proxy handles clients that disconnect mid-request instead of writing into dead sockets.
What's wrong with this entry?
The local network proxy used for sandboxed sessions now copes with clients that disconnect, are torn down, or flood it during connection setup, instead of writing responses into a dead socket. Before it emits any status response it re-checks that the socket is still writable and drops the decision if it is not, and it tears both ends of a failed tunnel down together.
- Data a client sends before the tunnel is established is captured and capped at 65536 bytes; exceeding the cap destroys the connection, logged as
CONNECT client exceeded pre-establishment capture cap; destroying. - Bytes captured during setup are replayed into the request buffer once the connection is established.
- Any socket error destroys the client socket.
- The writable check guards the 407 authentication-required, 403 forbidden, 200 tunnel-established and 502 bad-gateway responses, including the 403 that carries the
"X-Proxy-Error": "blocked-by-allowlist"header when a host is not on the allowlist. - Once a connection is established, half-open tunnels are permitted, so one direction closing no longer kills the other.
CONNECT client exceeded pre-establishment capture cap; destroying, "X-Proxy-Error": "blocked-by-allowlist"
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.239
Sandboxed CLIs get placeholder credentials so they route through the agent proxy
Both mention sandbox
-
v2.1.239
Per-tool memory limits detect an outer cgroup already in place
Both mention sandbox
-
v2.1.239
Memory limits on Linux notice when the process is already inside a managed group
Both mention sandbox