{"version":"2.1.317","anchor":"windows-sandbox-passes-late-added-deny-entries-per-command","canonical_anchor":"windows-sandbox-passes-late-added-deny-entries-per-command","heading":"Windows sandbox can apply blocks added after it started, command by command","tier":"notice","area":"Windows","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/windows-sandbox-passes-late-added-deny-entries-per-command","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### Windows sandbox can apply blocks added after it started, command by command\n\nOn Windows, blocked paths added after the sandbox started can now be applied to each sandboxed command, and a command is refused if they cannot be worked out\n\n**Unclear.** Whether this behaviour is switched on when the server sends nothing is not known.\n\n**What**\n\nThe sandbox is a restricted space Claude Code can run commands in, with a list of paths those commands are not allowed to touch. On Windows, that list is only applied when the sandbox starts, so paths blocked later, for example a new worktree (a separate working copy of a git repository), were missed.\n\nBehind a setting controlled from the server, Claude Code now adds those later blocks to each sandboxed command on Windows. If it cannot work out what those blocks are, it refuses to run the command. When the sandbox fails to start, Claude Code also records which blocked paths that are hard links (a second name for the same file) caused the failure.\n\n**Why**\n\nPaths blocked after the sandbox started can now be enforced on Windows too. The cost is that a sandboxed command can now fail with an error instead of running without those blocks.\n\n- Area: Windows\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}