{"version":"2.1.224","anchor":"sandbox-violations-record-the-command-that-caused-the-blocke","canonical_anchor":"sandbox-violations-record-the-command-that-caused-the-blocke","heading":"Sandbox violations record the command that caused the blocked request","tier":"notice","area":"Sandbox","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224\/e\/sandbox-violations-record-the-command-that-caused-the-blocke","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.224","markdown":"### Sandbox violations record the command that caused the blocked request\n\nBlocked network requests are now recorded with the command that made them, not just dropped.\n\n**What**\n\nA network request blocked by the sandbox is now recorded as a violation with its method, sanitized URL, reason and the command that made it, instead of only being dropped. Filesystem violations on Linux and macOS also gained command text.\n\n**Details**\n\n- Applies only while the sandbox proxy and platform monitors are running.\n\n**Evidence**\n\n`deny http-request `\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}