Reads were the one thing auto mode didn't ask about
Auto mode's classifier is built to block the actions that matter: force pushes, production deploys, secrets leaving a repository, mass deletion. Plain file reads were never part of that list, because a read on its own rarely causes damage the way a delete or a push does. That's also exactly why a read is a comfortable vector for a very different problem: a prompt-injected instruction, or a task that's simply gone further off the rails than intended, quietly pulling a file from somewhere your session was never scoped to touch. Nothing about auto mode's classifier stopped that before Claude Code v2.1.257.
That release, shipped 1 September 2026, added a narrower, more literal check that sits alongside the classifier rather than inside it: a one-time prompt before the first file read outside the session's working directories, with permissions.blockReadsOutsideWorkingDirectories as the setting that lets you decide the answer in advance instead of at that prompt.
What counts as "outside"
Claude Code's notion of working directories is already established outside this feature, and this check reuses it exactly. A read is inside your working directories when the path falls under:
- The session's primary working directory: where you launched
claude, or wherever you've since moved it with/cd - Any directory added with
--add-dirat startup or/add-dirduring the session - Any directory listed in
permissions.additionalDirectoriesin a settings file
Anything else, a path elsewhere on the filesystem that none of those three cover, is treated as outside for the purposes of this check. That's a deliberately blunt boundary, and deliberately so. It doesn't ask whether the file looks sensitive, the way the classifier's rules around secrets and credential stores do; it asks only whether the path is somewhere the session was ever told it could look.
The one-time prompt
Per the v2.1.257 changelog entry, Claude Code now shows "a one-time prompt in auto mode before the first file read outside the working directories, with the option to block such reads." Read literally, that's two things happening together: the prompt itself, which fires once per session the first time this situation comes up, and an option inside that prompt to make blocking the standing behaviour rather than a one-off decision.
That second part is what permissions.blockReadsOutsideWorkingDirectories configures ahead of time. Rather than waiting for the prompt and choosing block-going-forward interactively, set the key in your settings file and Claude Code applies that choice from the start of the session.
Setting it in advance
{
"permissions": {
"blockReadsOutsideWorkingDirectories": true
}
}
Place this in ~/.claude/settings.json for a personal default across every project, in a project's .claude/settings.json to scope it to that repository, or in managed settings to enforce it organization-wide. As with other permission keys, a managed-settings deployment is the way to guarantee every developer's session gets the same answer rather than relying on each person to click through the prompt the same way.
Claude Code's own settings reference hadn't published a dedicated entry for this key as of this writing, so the exact accepted value and default beyond the changelog's own wording aren't independently confirmed here. If you're deploying it in managed settings, check that page for your installed version before relying on details beyond what's stated above.
How this differs from a Read deny rule
Claude Code already has a mechanism for keeping specific paths off limits: a Read deny rule, such as Read(~/.ssh/**) or Read(//etc/**). That mechanism and blockReadsOutsideWorkingDirectories solve related but distinct problems.
Read deny rule | blockReadsOutsideWorkingDirectories | |
|---|---|---|
| Scope | A specific path or pattern you name | Anywhere outside the working directories, as a whole |
| Applies in | Every permission mode | Documented specifically for auto mode's one-time prompt |
| What you have to know in advance | The exact sensitive paths to exclude, like ~/.ssh or a credentials file | Nothing; it's a blanket boundary keyed to location |
| Typical use | Excluding a small number of known-sensitive locations from an otherwise trusted session | Catching reads you didn't anticipate at all, anywhere outside scope |
A Read deny rule requires you to have already thought of the path worth blocking. blockReadsOutsideWorkingDirectories doesn't; it flips the default so that anything you didn't explicitly bring into scope, via the working directory, --add-dir, or additionalDirectories, needs a deliberate decision before Claude Code reads it. The two are complementary rather than redundant: keep specific deny rules for paths you always want off limits regardless of scope, and use this setting to catch everything you never anticipated in the first place.
How this differs from the classifier's own judgment
Auto mode's classifier already treats "access to a location listed as a sensitive data location in your environment" as blocked by default, and treats everything not named in autoMode.environment as untrusted for actions like sending data externally. That's a content-and-destination judgment: it reasons about what a location is, sensitive personal data, a secret store, and what's happening to it.
blockReadsOutsideWorkingDirectories doesn't reason about content at all. It's a location check with no judgment call attached: is this path inside a working directory, yes or no. That makes it cheaper to reason about and harder to talk your way around with a plausible-sounding justification, at the cost of being blunter. A read of a perfectly innocuous file just outside your working directory, a shared config one level up, a sibling project's README, still trips the same boundary as a read aimed at something genuinely sensitive.
What this doesn't cover: sandboxed subprocess reads
It's worth being precise about the boundary, because Claude Code has a second, older mechanism that governs file reads and is easy to confuse with this one. sandbox.filesystem controls what sandboxed commands, not Claude's own Read tool, but subprocesses like kubectl, terraform, or a build script that a sandboxed Bash command starts, can touch at the OS level. By default, those sandboxed commands can read the rest of the filesystem, including credential files, and Claude Code narrows that only when you add entries to sandbox.filesystem.denyRead or set allowManagedReadPathsOnly.
That's a materially different default from what blockReadsOutsideWorkingDirectories targets. The new setting concerns Claude's own file-reading tools, the ones that show up as a Read call in your transcript. A sandboxed subprocess reading ~/.aws/credentials because a build script happened to cat it isn't a Read tool call at all, so this setting doesn't see it; that path runs through sandbox.filesystem's own read rules instead. If your threat model includes a subprocess a sandboxed command spawns, not just Claude reading a file directly, you need both: blockReadsOutsideWorkingDirectories for Claude's own reads, and an explicit denyRead entry, or allowManagedReadPathsOnly, for what sandboxed subprocesses can reach.
A worked example
Say you start a session scoped to one service in a monorepo:
cd services/billing
claude
Without --add-dir, the working directory is services/billing alone. If a task in that session, whether from your own prompt, a skill, or content Claude read along the way, leads it to read a file under services/auth or ~/.aws/credentials, that's a read outside the working directories. In auto mode, before v2.1.257 that read simply happened, subject only to the classifier's broader judgment about sensitive locations. From v2.1.257 on, the first such read triggers the one-time prompt; with blockReadsOutsideWorkingDirectories set ahead of time, it's blocked outright instead.
If the task genuinely needs services/auth in scope, the fix isn't to disable the setting, it's to bring that directory into scope deliberately:
claude --add-dir ../auth
or persistently, in services/billing/.claude/settings.json:
{
"permissions": {
"additionalDirectories": ["../auth"]
}
}
Either way, the read is now inside a working directory and the boundary no longer applies to it.
Part of a wider v2.1.257 hardening pass
This setting didn't ship alone. The same v2.1.257 release, 1 September 2026, also added a Containment Escape rule to auto mode that blocks cloud metadata-credential fetches, egress evasion, and cross-tenant reach unless your environment configuration marks them expected, and a /doctor warning for stale sandbox mask files left behind by a killed session. Taken together, the release reads as a single pass at auto mode's blind spots: one rule closing off a specific network-level escape route, one setting closing off unscoped file reads, and one diagnostic catching a cleanup failure that could otherwise leave a sandbox boundary weaker than intended. None of the three depend on each other, but they're worth knowing about together if you're deciding how much of this release to adopt at once.
Troubleshooting
A read that used to just happen now prompts or blocks. Check whether the path falls outside the session's primary working directory and every directory you've added with --add-dir, /add-dir, or additionalDirectories. If the task legitimately needs that path, add the directory explicitly rather than treating the prompt as a bug.
The setting doesn't seem to do anything. Confirm you're on Claude Code v2.1.257 or later (claude --version), and that you're in a permission mode where the documented behaviour applies. The changelog entry frames this specifically as an auto mode addition; if you're testing in a different permission mode and see no change, that's consistent with what's currently documented.
You want the boundary without the interactive prompt ever appearing. Set permissions.blockReadsOutsideWorkingDirectories in your settings file ahead of time, ideally in managed settings if you're deploying this across a team, so every session starts with the decision already made rather than surfacing the prompt once per session.
A teammate's session behaves differently from yours on the same repository. Check where each of you set the permission key. A value in your personal ~/.claude/settings.json doesn't propagate to anyone else; put it in the project's .claude/settings.json or in managed settings if you need every session on that repository, or in your organization, to agree.
You're not sure whether the boundary applies in your permission mode. The changelog attributes the one-time prompt specifically to auto mode. If you're running in Manual, acceptEdits, or bypassPermissions and want the same location boundary enforced regardless of mode, a Read deny rule anchored at the filesystem root for the paths you actually care about is the more reliable, mode-independent option until Claude Code's settings reference publishes the full scope of this key.
Where this fits
This setting is narrow by design: it's a location boundary, not a content classifier, and it sits alongside rather than inside auto mode's existing rule system covered in configuring auto mode's trusted infrastructure and auto mode's classifier rules from your own words. For the broader set of controls built for running Claude Code somewhere you don't fully trust the calling context, see Claude Code's --restricted flag, which confines file tools to the working directory as one part of a much wider lockdown. Browse the current settings and install paths at getclaudeskills.com/platforms/claude-code.
