{"version":"2.1.299","anchor":"sandbox-filesystem-rules-accept-literal-path-entries","canonical_anchor":"sandbox-filesystem-rules-accept-literal-path-entries","heading":"Sandbox filesystem rules can name exact paths","tier":"use","area":"Sandbox","scope":"both","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299\/e\/sandbox-filesystem-rules-accept-literal-path-entries","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299","markdown":"### Sandbox filesystem rules can name exact paths\n\nSandbox file rules can now mark a path as literal, so it is matched exactly rather than treated as a pattern\n\n**Unclear.** It is not stated which setting a reader writes literal path entries in.\n\n**What**\n\nThe sandbox is the protective boundary that limits which files commands run by Claude Code can read or write. Each entry in its filesystem rules can now be either a plain path or an object of the form `{ path, literal: true }`. A literal entry names one exact path and is not expanded like a wildcard pattern. Any other shape is rejected with an error saying a filesystem path entry must be a path, or `{ path, literal: true }`.\n\nOn macOS, the sandbox now builds separate literal versions of its allow and deny lists, including paths allowed inside a denied area, and keeps a list of the folders where writing is permitted.\n\n**Why**\n\nPinning an exact path means a rule cannot accidentally cover more or fewer files than intended, which directly affects what the sandbox lets through or blocks.\n\n- Area: Sandbox\n- Names: `literal`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: no"}