Imagine asking Claude Code to fix a checkout form while a separate client repository sits next to your app on the same laptop. A mistaken path could make a file-editing tool touch the wrong project. Claude Code v2.1.314, released on October 30, 2026, adds a setting for this precise boundary: permissions.blockWritesOutsideWorkingDirectories.

According to Anthropic's release notes, enabling it makes the Write, Edit, and NotebookEdit tools reject paths outside the working directories in every permission mode. That is a useful and narrow promise. It does not say that every shell command, test runner, or connected MCP server is confined by the same switch.

The decision this changes

If you use an AI coding agent for fast prototyping, the setting gives you a second boundary for the agent's native file edits. Suppose your active folder is ~/projects/store and a separate ~/projects/accounts folder contains sensitive work. When the latter is not among the working directories, those three file tools should refuse to edit it.

This matters most when a prompt refers to ambiguous relative paths, a refactor reaches across packages, or several repositories are open at once. It does not make all edits safe: the agent can still change the wrong file inside the allowed project. You still need code review, tests, and a clear scope for the task.

Set it up, then verify the boundary

Claude Code supports project settings in .claude/settings.json and personal settings in ~/.claude/settings.json, per its official settings guide. Put the following in your project file if you want the rule to travel with the repository; merge it with existing keys rather than overwriting them:

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true
  }
}

The snippet is valid JSON. You can check the file with python3 -m json.tool .claude/settings.json. The setting name comes directly from the v2.1.314 release note. I have not run Claude Code in a user account to verify the runtime behavior, so use the following as a safe acceptance test in your own environment, not as a claimed benchmark.

1. Update Claude Code and run claude --version; confirm 2.1.314 or later.
2. Open a disposable test project with the setting enabled. Keep real client data out of this test.
3. Create a second temporary folder beside it containing a throwaway text file. Ask Claude explicitly to use Edit on that outside file.
4. Check that the tool refuses the operation. Then ask for an edit inside the working directory and check that normal editing still works.
5. If you add more working directories to the session, repeat the test with the actual folder set. Your protection boundary follows that set.

What the setting does not claim

A Bash call can run a script that writes files. A connected MCP server may expose a separate write operation. The release note names only three Claude Code file tools; treating the setting as a universal filesystem sandbox would be an unsupported inference. For shell restrictions, review Anthropic's sandbox documentation, including filesystem permissions and escape hatches. For an MCP integration, inspect the server's capabilities and credentials independently.

My practical recommendation is to enable this rule when the agent should edit only its active project, keep sensitive repositories out of its working directories, test the rejection with disposable files, and review the diff before deploying. It closes a specific class of accidental edits. It is not a substitute for a broader security policy.

Primary sources: Claude Code v2.1.314 release (October 30, 2026); settings; sandboxing. Checked November 2, 2026.