{"version":"2.1.286","anchor":"bubblewrap-sandbox-for-project-hooks-on-linux-gated-by-teng","canonical_anchor":"bubblewrap-sandbox-for-project-hooks-on-linux-gated-by-teng","heading":"Cloud sessions running commands on your computer get a hook sandbox, auto-mode notices and hook-rewrite rules","tier":"notice","area":"Sandbox","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.286\/e\/bubblewrap-sandbox-for-project-hooks-on-linux-gated-by-teng","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.286","markdown":"### Cloud sessions running commands on your computer get a hook sandbox, auto-mode notices and hook-rewrite rules\n\nRemote tools gains a bubblewrap sandbox for project hooks, reasons for auto mode being off, and finer handling of hook input rewrites\n\n**Unclear.** What the further check requires, and exactly which hook runs take the Linux sandbox path.\n\n**What**\n\nRemote tools let a Claude Code cloud session run commands on your own computer. This release changes how such commands are approved and how project hooks run. A hook is a command your project sets up to run automatically at certain points.\n\n- Project hooks can run inside a bubblewrap (`bwrap`) sandbox, a walled-off area that limits what a program can see or do. It cuts the hook off from the network and other processes, gives read-only access to system folders, hides home folders, and applies extra limits through `\/run\/claude-hook\/apply-seccomp`.\n\n- The sandbox is tried once first. If it cannot be used, Claude Code logs \"[remote-tools] a project hook cannot be run in a sandbox on this machine\" with a reason such as `bubblewrap_too_old` (version 0.10.0 or later needed), `no_bubblewrap`, `no_seccomp_stage`, `bubblewrap_failed`, `home_in_view` or `credentials_in_view`.\n\n- On Linux this requires the server-controlled switch `tengu_violin_heel` to be true, not set as a local override, plus a further check. macOS does not use that switch. A second switch, `tengu_violin_saddle`, guards the path used when sandboxing or a proxy is active.\n\n- New messages explain why auto mode (Claude acting without asking each time) is off for unattended commands from cloud sessions: consent not given, declined or unreadable; turned off by `remoteTools.allowUnattendedServing` or `disableAutoMode`; or a built-in safety cut-off.\n\n- When a hook rewrites the input of a request that asked for approval, the rewrite is now classed as none, `own_hooks_alone` or unvouched. The message says the classifier answer was set aside only for unvouched rewrites. Before, it always said both the earlier answer and the classifier were set aside.\n\n**Why**\n\nYou now see why a cloud session is asking for approval on your machine. The most recent reading of `tengu_violin_heel`, taken before this release, was on for this site's account and the anonymous baseline. If the sandbox is in use, a Linux project hook that needs the network may fail.\n\n- Flag `tengu_violin_heel`: Off by default, switched on for this account (read for one account on one subscription tier against v2.1.286; this account: on, anonymous baseline: on, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Flag `tengu_violin_saddle`: Off by default, switched on for this account (read for one account on one subscription tier against v2.1.286; this account: on, anonymous baseline: on, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Sandbox\n- Names: `bwrap`\n- Tier: You'll notice\n- Useful: 5\/5\n- Signal: 5\/5\n- Present in the build but not switched on"}