Back to rankings

Claude Code Adds a Setting to Block File Writes Outside Your Working Directories

Claude CodeView original changelog

Claude Code 2.1.314 adds permissions.blockWritesOutsideWorkingDirectories, a setting that makes the Write, Edit and NotebookEdit tools refuse any path outside the session's working directories. The refusal applies in every permission mode, including the modes that normally skip prompts. It is the write-side counterpart to the existing setting that blocks reads outside the project.

Key Takeaways

  • Write, Edit and NotebookEdit now have a hard boundary, because permissions.blockWritesOutsideWorkingDirectories makes them refuse paths outside the working directories.
  • The refusal applies in every permission mode, so skipping prompts no longer means skipping the fence.
  • The setting is the write-side twin of the existing read-blocking option, letting a session be confined in both directions.
  • It removes the dependency on a person spotting a bad path in an approval prompt, which matters most in unattended runs.
  • Bash commands are not covered by this setting, so shell activity still relies on permission rules and the sandbox.
  • Anyone who needs to edit elsewhere can keep it off or add the extra folders as working directories.

A hard fence around where Claude can write

Claude Code 2.1.314 adds a new permissions setting, permissions.blockWritesOutsideWorkingDirectories. When it is turned on, the Write, Edit and NotebookEdit tools refuse to touch any path that sits outside the session's working directories. Anthropic states that the refusal holds in every permission mode.

That last detail is the important one. Permission modes decide how often Claude Code stops to ask before acting, and some modes are built to ask as little as possible. A prompt-based safeguard depends on the person noticing and declining a bad path. A setting that rejects the path outright does not depend on anyone paying attention, so the boundary stays fixed even during long unattended runs.

Why it matters

Coding agents routinely work in a project folder while having access to the whole user account. A mistaken relative path, a symlinked folder or a misunderstood instruction can send an edit to a dotfile, a sibling repository or a system location. Teams have wanted a durable way to say "this session may change files here and nowhere else".

The setting follows an earlier companion option for reads. permissions.blockReadsOutsideWorkingDirectories refuses reads outside the working directory regardless of mode. With both in place, a session can be confined on both sides: what it can look at and what it can change.

What it does not cover

The setting is scoped to the three file-editing tools named in the release notes. Shell commands run through the Bash tool are governed by the separate permission rules and sandbox settings, so people who need to confine shell activity should keep those controls enabled as well.

Who should turn it on

The option suits shared machines, CI-style unattended runs, sessions started in bypass or auto-approve modes, and any setup where an agent works next to sensitive folders. Users who legitimately edit files outside the project can leave it off or add the extra directories to the session's working directories.