{"version":"2.1.302","anchor":"sandbox-error-reporting-table-and-native-windows-folder-secu","canonical_anchor":"sandbox-error-reporting-table-and-native-windows-folder-secu","heading":"Windows sandbox folder permissions use the runtime, with named sandbox errors","tier":"internal","area":"Elsewhere","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.302\/e\/sandbox-error-reporting-table-and-native-windows-folder-secu","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.302","markdown":"### Windows sandbox folder permissions use the runtime, with named sandbox errors\n\nOn Windows, sandbox folder permissions are now read and changed through Claude Code's runtime, and sandbox errors use a table of named messages\n\n**What**\n\nA sandbox is a restricted environment that limits which files and folders the commands Claude runs can touch. Two things changed in how Claude Code handles it:\n\n- Sandbox errors are now reported from a table of named messages, such as \"sandbox: failed to initialize\".\n\n- On Windows, reading and changing folder permissions now goes through a built-in feature of the runtime Claude Code runs on, instead of calling Windows system functions directly.\n\nIf the runtime does not have that feature, Claude Code logs a message saying folder permissions can be neither read nor changed, and asks you to run the pinned `@anthropic-ai\/bun-internal` runtime.\n\n**Why**\n\nThis lays groundwork for sandboxing on Windows and gives sandbox failures clearer, consistent names.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}