Claude Code: Block Reads Outside the Working Directory
Claude Code can read files outside the directory you launched it in, and in auto mode it does so without asking. If you want a hard fence instead, there is one setting for it: permissions.blockReadsOutsideWorkingDirectories. This page covers what it fences, the places it does not reach, and the rule about which directories count as inside.
Verified 2026-11-01 against the settings reference, the permission modes page and the changelog at code.claude.com (newest changelog entry was 2.1.316). We did not run a live session for this page, so everything below is what the docs state.
What does the setting do?
Set it to true and Claude's file tools refuse reads outside your working directories in every permission mode, including bypassPermissions. The docs say Claude Code denies Read, Grep, Glob and LSP calls on those paths and tells Claude to ask you to add the directory with /add-dir. It needs v2.1.257 or later.
{
"permissions": {
"blockReadsOutsideWorkingDirectories": true
}
}
Files Claude Code needs for itself stay readable: your skills, plugins, rules, agents, commands, and the CLAUDE.md memory file under ~/.claude/.
Without the setting, behavior depends on mode. In auto mode, reads run without a prompt, outside the working directories too, except that the first time Claude uses Read, Grep or Glob on an outside path, Claude Code asks once. Interactive sessions only: the prompt does not appear in -p runs or background sessions, so unattended jobs read outside the directory with no question asked.
Who can turn it on, and who can turn it off?
The scope is "any file". A true in any settings file applies, and false is the same as unset. The docs spell out the consequence: a repository can turn the block on for itself but cannot lift yours. To lift it, remove the key from every file that sets it and start a new session.
You can also get it without editing JSON. The auto mode prompt offers No, and block reads outside the working directories from now on, which writes true to your user settings.
Which directories count as inside?
The working directory you launched in, plus directories you add with --add-dir, /add-dir, or additionalDirectories in your user or managed settings. The catch is the last clause of that list. Directories added only in repository settings do not count: that means .claude/settings.json, and .claude/settings.local.json unless git reports that file as untracked. In a directory that is not a git repository, or when git tracks the file, the local file is treated as repository settings too.
So if a checked-in additionalDirectories entry points at ../shared-config and you have the block on, reads there are refused. Put directories you want readable in your user settings.
What does it not cover?
Shell commands. The docs say Claude Code does not refuse them the same way. What happens instead:
- Recognized file-reading Bash commands that touch an outside path prompt you even in auto mode and
bypassPermissions, as does an unsandboxed retry that needs approval to run outside the sandbox. - A command the shell parser cannot trace, such as one that changes directory more than once or runs a subshell, prompts too, even if it names no outside path.
- None of those prompts apply when the command runs in the sandbox and the sandbox enforces the block.
The practical reading: the setting is a fence for the file tools and a prompt trigger for Bash. If an unattended job must never read outside its directory, the fence is the setting plus a sandbox, not the setting alone. Where the sandbox cannot run, the "prompt" means the job stops and waits, which in a headless run is a failure you should expect and test.
Is there a writes version?
The changelog says so. Version 2.1.314 (2026-10-30) lists: "Added permissions.blockWritesOutsideWorkingDirectories: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode".
As of today we could not find that key in the settings reference, so we cannot tell you its scope rules, whether Bash is covered, or whether additionalDirectories counts the same way. Treat the reads rules above as documented and the writes key as announced. Check the settings reference for the section before you depend on it, and if it exists, test with a path outside the directory before you trust it.
FAQ
Does blockReadsOutsideWorkingDirectories work in bypassPermissions mode?
Yes for the file tools. The docs say it applies in every permission mode, including bypassPermissions. Bash reads of outside paths prompt even there.
Can a repository's settings file undo it?
No. A true in any file applies, so a project file can add the block but cannot remove one you set.
Does it stop cat /etc/passwd in Bash?
It does not refuse it, it prompts. A recognized file-reading command on an outside path asks you even in auto mode and bypassPermissions, unless a sandbox that enforces the block is running the command.
Which version do I need?
v2.1.257 or later for the reads setting.