{"version":"2.1.300","anchor":"new-unsandboxed-cli-flag-recognised","canonical_anchor":"new-unsandboxed-cli-flag-recognised","heading":"New --unsandboxed flag and a sandbox-VM-by-default decision at session start","tier":"use","area":"Sandbox","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300\/e\/new-unsandboxed-cli-flag-recognised","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300","markdown":"### New --unsandboxed flag and a sandbox-VM-by-default decision at session start\n\nSession start can now place a session in a sandbox VM by default, and a new --unsandboxed flag opts out of that and of cloud-by-default\n\n**Unclear.** It is unclear whether `--unsandboxed` is a flag users can pass or only an internal entry, and what it does.\n\n**What**\n\nWhen a session starts, Claude Code now makes a second decision alongside the existing one about running in the cloud by default. The new decision is about a sandbox VM, an isolated virtual computer the session runs in, kept separate from your own machine. The decision ends as none, declined or applied. It applies when:\n\n- the `sandboxVmByDefault` option is set,\n\n- the session is eligible, and\n\n- you did not pass unsandboxed.\n\nRelated changes:\n\n- `--unsandboxed` is a new command-line flag Claude Code recognises. It is added to a list of flag names that also holds `--remote-control`, `--rc` and `--local`. What that list is used for was not traced.\n\n- The cloud-sessions-by-default decision now also counts unsandboxed as declining it, the same as `--local`. Before, only local declined it.\n\n**Why**\n\nWhere these defaults are switched on, a session may start in a sandbox VM or in the cloud without you asking. Passing `--unsandboxed` is the way to stay out of both.\n\n- Area: Sandbox\n- Tier: Use it now\n- Useful: 5\/5\n- Signal: 4\/5\n- Scope: individual\n- Heads-up: yes"}