Blocked outbound connections now name the shell command responsible.
What's wrong with this entry?
When the sandbox blocks an outbound connection, the violation record now includes the shell command responsible, so you can tell which command tried to reach the network rather than only seeing that something did.
- The proxy's auth check returns a result object carrying an encoded command instead of a plain yes/no.
- The proxy Basic credential username may now be
srtorsrt.<suffix>; the SOCKS path previously required an exactsrtmatch. The suffix decodes to the command identity, set fromSRT_ENCODED_CMDwhen a command id is supplied. - The decoded command is passed to the allowlist filter and to the denial callback, and violation records carry both the encoded form and a resolved command string.
- Requests failing the auth check still get the existing 407 and 403 responses.
SRT_ENCODED_CMD, encodedCommand
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.236
macOS sandbox re-applies read and delete denials inside writable folders
Both mention sandbox
-
v2.1.236
Sandbox proxy no longer writes to sockets that have gone away
Both mention sandbox
-
v2.1.236
IPv6 hosts through the proxy
Both mention sandbox