Once it is on, can Bash still write outside the project?
Yes. Per the article, the setting governs only Write, Edit and NotebookEdit, and shell redirects, MCP tools and hook programs are out of scope.
Blocking those takes a Sandbox in addition.
Can a project's settings turn it on for itself, and also turn it off for me?
It can turn it on but not off. Per the article, project settings can enable it for themselves but cannot lift a Block the user has set; a true in any loaded file applies.
To fully turn it off, delete the key from every file that sets it and restart.
I use worktrees. Will I be affected?
Yes. The article says EnterWorktree and ExitWorktree are removed or refused while it is on, and Subagent worktrees outside the working directories are refused writes too.
If your workflow depends on isolation: worktree, confirm in a test project before rolling it out.
How are symlinks handled?
The article does not say how symlinks are handled, nor how paths are normalized. I found no official documentation that fills this in.
Before relying on the setting to protect an important directory, I would test it with a link you create that points outside the project.
Claude Code v2.1.314 (October 30, 2026) added permissions.blockWritesOutsideWorkingDirectories: when on, Write, Edit and NotebookEdit refuse paths outside the working directories, identically in every permission mode. The changelog gives one line; the details come mainly from a third-party write-up by Developers Digest, and I did not read the official documentation directly, so I mark below what the article leaves unclear.
The setting lives in the permissions object of ~/.claude/settings.json. It is a boolean, unset by default, with false equivalent to unset, and needs v2.1.314 or later. The article says any loaded settings file can set it; a true in any one file applies, even if a managed source sets false. A project's own settings can turn it on for itself but cannot lift a Block the user has set. The article says it refuses in every mode, including bypassPermissions.
It governs only the three file tools: Write, Edit and NotebookEdit. Out of scope are shell commands (a redirect such as echo x > ~/file), MCP tools, and programs run by hooks, which the article says need a Sandbox. A few things can still be written outside the project: plan files, the session scratchpad, a background session's tmp directory, and .md files in the project's auto memory.
The article lists several writes refused even within working directories: Claude Code's own settings files (so a settings file cannot lift the block), directories added only through a project's additionalDirectories, .claude/settings.local.json unless git reports it as untracked, Subagent worktrees outside the working directories (isolation: worktree), and an autoMemoryDirectory set through project settings. A side effect is that EnterWorktree and ExitWorktree are removed or refused while it is on.
The article gives no full definition, only the ways to add one: /add-dir during a session (the directory must exist), --add-dir at startup, or additionalDirectories in user or managed settings. Allow rules do not let file tools past the block, and a directory listed only in the project's .claude/settings.json does not count. If Claude Code cannot read the permissions object in managed settings, the block stays on. Cloud sessions might not apply the key. How symlinks are handled and how paths are normalized, the article does not say.
To test, ask Claude to use the Write tool to create ~/block-test.txt (assuming home is not a working directory); the refusal names the permissions.blockWritesOutsideWorkingDirectories setting. To remove it, delete the key from every file that sets it and restart; a false in one file does nothing while another file still says true.
Before letting an agent run unattended, this setting is a cheap first layer of insurance: one wrong path overwriting a file in your home directory costs far more to repair than five minutes spent flipping a boolean. But do not conclude that writes are now controlled: Bash redirects, MCP tools and hook programs are out of scope, and the real boundary still needs a sandbox. Turn it on in a test project first, verify the refusal with the method above, then push it to your team's managed settings; also check whether you rely on worktrees or project-level additionalDirectories, since those will be blocked along with it.