One unreadable Docker folder silently switched off Claude Code's .env read block (unverified report)

What happened

A Japanese developer set sandbox.filesystem.denyRead: ["**/.env"] in Claude Code’s project settings on Linux, where the sandbox runs on bubblewrap. The idea was simple: whatever the agent does, it should never read an environment file. In one project that worked. In another project, with the same settings, the agent could read nested .env files freely.

The chaos on the ground

There was no error, no warning, nothing in the logs. The only clue was the difference between two projects. The author compared them and found that the broken one contained a folder created by Docker for a PostgreSQL volume, owned by another user ID with permissions the host user could not enter. Creating a single empty folder with chmod 000 was enough to reproduce the problem anywhere.

Root cause

To turn **/.env into concrete paths, the sandbox listed every file under the project with a recursive directory read. That call does not skip folders it cannot open; it stops at the first permission error. The code caught the error and carried on with an empty list, so the rule quietly protected nothing. Rules with fixed paths never went through that step, which is why ./.env stayed blocked.

The fix

According to the author, Anthropic’s open-source sandbox runtime has since replaced the recursive listing with a walk that continues past permission errors and masks the folders it cannot read, but the Claude Code release they tested had not yet taken in that change. Until it does, the author suggests narrowing wildcards to the folders that matter, listing important .env files by fixed path, moving Docker volumes out of the project tree, and layering several patterns.

The wider lesson is about how security settings get checked. A deny rule that fails open looks exactly like one that works. The only reliable test is to have the agent try to read the file it should not be able to read, in every project, after every change.