Sandbox read-deny rules now cover masked secret files and trim default writable paths

What

The sandbox limits which files commands run by Claude can read and write. How its read-deny rules are built has been reworked.

• Masked secret files that cannot be masked with a bind, a way of hiding a file's contents, now fall back to being denied outright. The masking setup returns a new list, degradeToDenyPaths, which is added to the deny rules.
• On macOS, the sandbox profile takes a new libraryDenyEntries list, built from the real paths of masked files plus degradeToDenyPaths. It now writes read restrictions even when you have not set any denyRead. Claude Code logs that a file mask on macOS degrades to a deny "until the interposer lands".
• The write allowlist is now worked out from denyRead, allowRead and credential settings together. denyRead entries go through a helper that can turn them into deny paths and collects unlistableDenyDirs. Before, denyRead and allowRead were expanded separately and the write allowlist was only the defaults plus allowWrite.
• The home paths the sandbox always made writable, .npm/_logs and .claude/debug, are now left out when a filesystem.denyRead entry or a credentials file set to deny covers them, unless allowRead allows them again.
• Updating sandbox settings now also recomputes the network domain policy through the same path.

Why

Secret files are no longer left readable when masking them fails, and a denyRead covering your home directory no longer leaves those two default paths writable. Expect more paths to be blocked for sandboxed commands when denyRead or credential masking is configured, especially on macOS.