{"version":"2.1.227","anchor":"device-bash-refuses-on-any-machine-whose-sandbox-is-not-full","canonical_anchor":"device-bash-refuses-on-any-machine-whose-sandbox-is-not-full","heading":"device_bash refuses on any machine whose sandbox is not fully confining","tier":"soon","area":"Cloud Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.227\/e\/device-bash-refuses-on-any-machine-whose-sandbox-is-not-full","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.227","markdown":"### device_bash refuses on any machine whose sandbox is not fully confining\n\nThe local-command tool refuses to run unless your sandbox is strict and fully confining.\n\n**What**\n\nBefore running anything, the local-command tool checks the device's sandbox and refuses with a specific reason if sandboxing is off or unsupported on the platform, failed to start, is not in strict mode, allows all Unix sockets, or is set to inject real credentials into network requests. Each refusal returns an error saying what to change on that device.\n\n**Details**\n\n- successful runs emit `tengu_device_bash_served` with whether the exit code was zero, duration, whether output was truncated, and whether the session matched\n- separate events cover timeouts, output limits, cancellation and failures\n- refusals carry distinct reason codes, so a device that never runs commands can be told apart from one that ran and failed\n\n**Evidence**\n\n`tengu_device_bash_served`\n\n- Area: Cloud Sessions\n- Tier: Nothing to try yet\n- Useful: 3\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}