{"version":"2.1.284","anchor":"sandbox-settings-reject-deny-globs-that-end-in-a-path-separa","canonical_anchor":"sandbox-settings-reject-deny-globs-that-end-in-a-path-separa","heading":"Sandbox deny rules ending in a slash are now flagged as invalid","tier":"notice","area":"Sandbox","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284\/e\/sandbox-settings-reject-deny-globs-that-end-in-a-path-separa","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284","markdown":"### Sandbox deny rules ending in a slash are now flagged as invalid\n\nSandbox deny paths that end in a slash now show a validation error, because they matched nothing and protected nothing\n\n**Unclear.** It is not clear whether this error stops the settings from loading or is only reported.\n\n**What**\n\nThe sandbox is the restricted space Claude Code runs commands in. Its settings can deny access to files. Claude Code now checks deny entries in these places:\n\n- `filesystem.denyRead`\n\n- `filesystem.denyWrite`\n\n- `credentials.files` entries whose mode is \"deny\"\n\nAn absolute path, or a path starting with `~`, that ends in a separator such as `\/` is now reported, because such a pattern can match no path. The message suggests removing the trailing slash or adding `**` at the end. The check only runs when filesystem sandboxing is not turned off.\n\n**Why**\n\nBefore this, a deny rule written with a trailing slash silently protected nothing. It is now reported, so you can fix it.\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}