{"version":"2.1.224","anchor":"sandbox-network-denials-name-the-command-that-caused-them","canonical_anchor":"sandbox-network-denials-name-the-command-that-caused-them","heading":"Sandbox network denials name the command that caused them","tier":"notice","area":"Sandbox","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224\/e\/sandbox-network-denials-name-the-command-that-caused-them","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224","markdown":"### Sandbox network denials name the command that caused them\n\nBlocked outbound connections now name the shell command responsible.\n\n**What**\n\nWhen 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.\n\n**Details**\n\n- The proxy's auth check returns a result object carrying an encoded command instead of a plain yes\/no.\n- The proxy Basic credential username may now be `srt` or `srt.<suffix>`; the SOCKS path previously required an exact `srt` match. The suffix decodes to the command identity, set from `SRT_ENCODED_CMD` when a command id is supplied.\n- 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.\n- Requests failing the auth check still get the existing 407 and 403 responses.\n\n**Evidence**\n\n`SRT_ENCODED_CMD`, `encodedCommand`\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 1\/5"}