Claude Code Can Now Refuse to Write Outside Your Project, in Every Permission Mode

Most of the scary Claude Code stories I hear are not about the model going rogue. They're about a file landing somewhere nobody was looking. A config written into a home directory. An edit that followed a path one folder too far up. Nothing dramatic, just a change in a place that was never part of the project.

On October 30, Claude Code v2.1.314 shipped a setting aimed squarely at that: permissions.blockWritesOutsideWorkingDirectories.

What shipped

The changelog entry for 2.1.314 says it makes Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode. That last phrase is the point. Permission modes decide when Claude asks you before acting. This setting isn't about asking. It's a fence, and the fence holds whether you're in manual mode, auto mode, or something looser.

It has a sibling that shipped earlier. permissions.blockReadsOutsideWorkingDirectories does the same job for reads, and the permissions docs note that in auto mode Claude Code will offer to turn it on the first time Claude reads outside the working directories. The write version completes the pair.

One caution on sourcing: as I write this, the changelog line is the only place I found the write setting described. The reads setting has a full reference entry. I'm treating the two as parallel, but I haven't seen the write setting's reference page, so check it before you rely on any edge case.

Why a fence beats a prompt

A permission prompt asks a tired human to make a good decision at 4 PM. A fence makes the decision once, in a file, when you're awake.

That matters most in auto mode and in anything that runs unattended: routines, cloud sessions, scheduled work, a long autonomous run you walked away from. In those, nobody is there to read the prompt. A rule that says "writes stay inside the project" doesn't depend on anyone paying attention.

It also matters for teams. If you commit the setting, everyone who clones the repo gets the same boundary. Per the settings docs, shared project settings in .claude/settings.json reach teammates, and your personal overrides live in .claude/settings.local.json.

What it doesn't do

I want to be straight about the limits, because "blocks writes" gets misread as "sandbox."

• It names three tools. The changelog lists Write, Edit and NotebookEdit. A shell command is a different tool with different rules. If Claude runs echo x > ~/somewhere, that goes through your Bash permissions, not this setting. If your concern is shell writes, you need your Bash allow and deny rules, or a real sandbox, doing that job.
• It follows your working directories. If you've added extra directories with permissions.additionalDirectories or --add-dir, those are working directories too. The fence sits around the whole set, so audit that list before you trust the boundary.
• It's one layer. It limits where the file tools can write. It doesn't review what they write inside the project.

The settings file I'd use

Here's what I'd put in a project's shared file:

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true,
    "blockReadsOutsideWorkingDirectories": true
  }
}

Then run /status to confirm the file loaded, and try the obvious test: ask Claude to edit something in your home directory and watch it get refused. Don't skip the test. A setting you've never seen fire is a setting you're guessing about.

What I'd do this week

1. Run claude --version. You need 2.1.314 or later for the write setting.
2. Look at your additionalDirectories and --add-dir habits. Trim anything that's there out of convenience.
3. Turn on both fences in the shared project file of any repo where Claude runs without you watching.
4. Keep your Bash deny rules. This setting doesn't replace them.

If you're rolling Claude Code out to a team and want the permission model, settings files and guardrails set up once and correctly, that's the core of what I do in private team training and 1:1 coaching. The primary sources for everything above are the Claude Code changelog, the permissions page and the settings reference.