{"version":"2.1.281","anchor":"sandboxed-bash-failures-reported-to-the-remote-caller","canonical_anchor":"sandboxed-bash-failures-reported-to-the-remote-caller","heading":"Sandboxed Bash failures reported to the remote caller","tier":"internal","area":"Sandbox","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/sandboxed-bash-failures-reported-to-the-remote-caller","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Sandboxed Bash failures reported to the remote caller\n\nWhen a sandboxed Bash command fails or records a sandbox violation, Claude Code now sends a sandboxed_failure note to the remote caller\n\n**Unclear.** The finding does not say who the remote caller is or what it does with the note.\n\n**What**\n\nThe Bash tool runs shell commands for Claude. Some commands run in a sandbox, a restricted area that limits what the command can touch. When a sandboxed command fails, or when the sandbox records a violation (the command tried to do something it was not allowed to), the tool now sends a note with the key `\"sandboxed_failure\"` and a `violationRecorded` value to the remote caller. Commands that were interrupted are not reported.\n\n**Why**\n\nWhatever is driving Claude Code from the other end now learns that a sandboxed command failed, and whether the sandbox caught a violation, instead of only seeing the command's output.\n\n- Area: Sandbox\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}