Claude Code Patches a macOS Sandbox Wildcard Deny-Rule Bypass
Claude CodeAnthropic hardened Claude Code's macOS sandbox in version 2.1.236 by fixing how wildcard read-deny rules are enforced. Previously, a rule such as denying **/.env could be sidestepped inside an otherwise-allowed read region, and simply renaming a protected file could slip it past the wildcard match entirely. The fix makes wildcard deny rules take precedence within allowed read regions, extends protection to a matched directory's full contents, and closes the rename-based bypass, so files developers explicitly protect (credentials, secrets, .env files) stay protected.
Key Takeaways
- A real sandbox protection gap is now closed: wildcard read-deny rules like
**/.envpreviously could be overridden inside allowed read regions on macOS. - A rename-based bypass is now blocked: renaming a protected file could previously remove it from a wildcard deny rule's coverage; that loophole is fixed.
- Protection now extends to full directory contents: a wildcard match against a directory now covers everything inside it, not just exact filename matches.
- This is a trust-boundary fix, not a feature: it strengthens an existing security guarantee rather than adding new functionality, making it high-value for anyone relying on deny rules around secrets.
- macOS-specific: the bug and fix are scoped to Claude Code's macOS sandbox implementation.
- Part of a pattern: this is at least the second wildcard/deny-rule sandbox bypass Anthropic has patched in Claude Code in recent months, following an unrelated trailing-slash bypass fixed in early August.
What Was Broken
Claude Code's sandbox lets developers explicitly deny read access to sensitive paths, commonly using wildcard patterns like **/.env to protect secrets anywhere in a project tree. Before version 2.1.236, this protection had a gap on macOS: a wildcard deny rule could be overridden inside a directory the sandbox otherwise treated as an allowed read region, and a file could dodge the deny rule entirely by being renamed to something the wildcard pattern no longer matched.
In practice, this meant a deny rule a developer believed was protecting a credentials file could quietly stop applying — either because of how allowed and denied regions overlapped, or because an agent (or a crafted prompt) renamed the file before reading it. Either path defeats the purpose of a deny rule: giving users confidence that specific files are off-limits to the agent regardless of what commands run.
The Fix
Anthropic closed both gaps in the same release. Wildcard read-deny rules now take precedence inside allowed read regions rather than being overridden by them, the rules now cover the full contents of any matched directory rather than only exact path matches, and renaming a denied file no longer removes it from the wildcard's protection.
Why It Matters
This falls squarely in the trust-boundary category: it is a fix to the sandbox's permission enforcement, not a UI or workflow change. Developers who rely on deny rules to keep Claude Code away from .env files, SSH keys, or other credentials on macOS should treat this as a reason to update, since the previous behavior could have created a false sense of security around exactly the kind of protection those rules exist to provide.