{"version":"2.1.299","anchor":"sandboxed-git-on-windows-gets-a-generated-global-gitconfig-c","canonical_anchor":"windows-sandbox-install-passes-program-permission-result-to","heading":"Windows sandbox setup grants more permissions, prepares git identity and explains failures better","tier":"notice","area":"Sandbox","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299\/e\/sandboxed-git-on-windows-gets-a-generated-global-gitconfig-c","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299","markdown":"### Windows sandbox setup grants more permissions, prepares git identity and explains failures better\n\nOn Windows, sandbox setup now grants folder and executable access, gives sandboxed git your name and email, and reports more on failures\n\n**What**\n\nThe sandbox is a fenced-off area where Claude Code runs commands so they can only reach what they are allowed to. `\/sandbox` is the command that turns sandbox mode on. On Windows, setting up this sandbox now does more work:\n\n- Program-permission step: installing through `\/sandbox` now runs a step that sets program permissions before the step that trusts the sandbox's certificate (the CA used for TLS inspection, which lets the sandbox look inside secure web traffic). The result of that step is added to the failure message, such as \"The sandbox TLS inspection CA couldn't be trusted for the sandbox user\".\n\n- Git identity: each session gets its own generated global gitconfig file (git's settings file) holding your git `user.name` and `user.email`, so git commands run in the sandbox can make commits. The file is locked down with `icacls` (`\/inheritance:r`, `\/grant:r`). If it cannot be prepared, a warning says sandboxed git will not see your global `user.name` and `user.email`, so a commit may fail unless the repository sets them.\n\n- Parent folders: Claude Code adds access entries (ACL entries, Windows' per-folder permission lists) for the sandbox group on the folders above your project. Without them, the logs say, sandboxed PowerShell commands may start in the drive's root and Node may fail with EPERM. Setting the environment variable `CLAUDE_CODE_SANDBOX_LEAVE_PARENT_FOLDERS_ALONE` turns these parent-folder grants off.\n\n- Claude executable: the sandbox group gets read and execute rights on the claude executable through `icacls`.\n\n- Refusal to start: the sandbox will not start when the working folder is your home folder, a folder that contains your home folder, or the config folder.\n\n- Other additions: deny entries specific to Bun (the runtime Claude Code is built on), and a new error when the block of environment variables is too long.\n\n**Why**\n\nThese steps change permissions on real folders on your Windows machine, not just inside the sandbox, so it helps to know they happen and that `CLAUDE_CODE_SANDBOX_LEAVE_PARENT_FOLDERS_ALONE` exists to stop the parent-folder part. Commits from inside the sandbox should no longer fail just because git has no identity, a failed install says more about what went wrong, and starting a sandboxed session from your home folder is now refused.\n\n- Area: Sandbox\n- Names: `user.name`, `user.email`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: yes"}