{"version":"2.1.290","anchor":"sandbox-read-deny-paths-accept-relative-and-spellings","canonical_anchor":"sandbox-read-deny-paths-accept-relative-and-spellings","heading":"Sandbox read-block paths now work when written with ~ or as relative paths","tier":"notice","area":"Sandbox","scope":"both","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290\/e\/sandbox-read-deny-paths-accept-relative-and-spellings","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.290","markdown":"### Sandbox read-block paths now work when written with ~ or as relative paths\n\nPaths you block from reading in the sandbox can now start with ~ or be relative, and Claude Code turns them into full paths\n\n**Unclear.** The full effect of the new path resolution steps is not clear.\n\n**What**\n\nThe sandbox limits which files and folders commands may touch. You can list paths that commands may not read. Those paths can now start with `~` (your home folder) or be relative (written from the current folder), and Claude Code converts them into full paths before applying them.\n\nThe note shown when a credential-hiding rule is dropped, because a read block already covers the same file, now says the block may cover it through a symlink or a relative spelling. Before, it only mentioned symlinks.\n\n**Why**\n\nA block written as `~\/something` or as a relative path could otherwise fail to protect the file you meant.\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: both\n- Heads-up: no"}