{"version":"2.1.304","anchor":"sandbox-filesystem-deny-lists-are-merged-through-one-shared","canonical_anchor":"sandbox-filesystem-deny-lists-are-merged-through-one-shared","heading":"Sandbox credential paths are now kept apart from other read restrictions","tier":"internal","area":"Sandbox","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304\/e\/sandbox-filesystem-deny-lists-are-merged-through-one-shared","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304","markdown":"### Sandbox credential paths are now kept apart from other read restrictions\n\nSandbox block lists are now built in one shared place, and credential paths stay in their own list instead of joining `denyRead`\n\n**What**\n\nThe sandbox is the restricted space Claude Code runs commands in, with lists of paths it may not read (`denyRead`) or write (`denyWrite`). These lists, both for each command run in the Windows sandbox and for the session as a whole, are now built by a single shared step.\n\nTwo things are different:\n\n- Credential paths, the locations of passwords and keys the sandbox protects, are kept in their own list and are no longer added into `denyRead`.\n\n- When `filesystem.disabled` is set, the sandbox grants no file access at all, apart from adding any extra blocked paths passed in.\n\n**Why**\n\nThe way block rules are combined has changed, which can affect exactly which paths end up blocked. If you rely on specific paths being denied, it is worth checking they still are.\n\n- Area: Sandbox\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}