{"version":"2.1.323","anchor":"windowslinux-sandbox-allowwrite-grants-that-could-be-re-po","canonical_anchor":"windowslinux-sandbox-allowwrite-grants-that-could-be-re-po","heading":"Sandbox withholds write access to paths that could be redirected","tier":"notice","area":"Sandbox","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/windowslinux-sandbox-allowwrite-grants-that-could-be-re-po","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Sandbox withholds write access to paths that could be redirected\n\nThe Windows and Linux sandbox now refuses an allowWrite grant whose path leads elsewhere or to nothing yet, and logs why\n\n**Unclear.** Whether this check applies to every sandbox setup or only some.\n\n**What**\n\nThe sandbox now holds back an `allowWrite` grant (a path you allowed sandboxed commands to write to) when that path does either of these:\n\n- leads somewhere other than its own spelling, for example through a shortcut-style link\n\n- leads to nothing that exists yet\n\nIn both cases a sandboxed command could re-point the path somewhere else. The log notes the grant as withheld and suggests spelling the grant by its real path.\n\nSeparately, when `blockReadsOutsideWorkingDirectories` applies, one more configuration folder is added to the folders re-opened despite `denyRead`.\n\n**Why**\n\nWrite access granted through a redirectable path is now stricter. If a write grant stops working, list the real folder rather than a link to it.\n\n- Area: Sandbox\n- Names: `allowWrite`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}