Claude Code Can Now Block Writes Outside Your Project

Can you stop an AI coding agent from changing files outside your project? As of Claude Code 2.1.314, released on 30 October 2026, yes, at least for its file-editing tools. A new setting, permissions.blockWritesOutsideWorkingDirectories, makes the tools Write, Edit and NotebookEdit refuse any path outside the working directories, in every permission mode.

This article explains what changed, what the setting does and does not cover, and what it means for a team that builds software with an AI agent. Where the documentation is thin, I say so.

What changed in Claude Code on 30 October 2026?

The Claude Code changelog lists this entry under version 2.1.314, dated 30 October 2026:

Added permissions.blockWritesOutsideWorkingDirectories: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode

Some plain-English terms first:

• Working directory. The folder you start Claude Code in, plus any extra folders you have added on purpose. This is the area the agent is meant to stay inside. ("Directory" is another word for folder.)
• Permission mode. How much the agent may do before it asks you. Some modes ask often. Others ask rarely or never.
• Write, Edit and NotebookEdit. The agent's built-in tools for creating and changing files.
• Setting. An option you switch on in one of Claude Code's configuration files.

Before this setting, a person approving each step was the main check on where files were changed. In the relaxed modes that check is mostly gone. The new setting is a rule that sits above the mode, so changing the mode does not lift it.

Why would an agent write outside the project?

Usually by accident, and usually for a reason that looks sensible. An agent fixing a build problem may decide to edit a shared configuration file in your home folder. It may change a neighbouring project it came across while searching. Or it may save a generated file one level too high.

None of this needs bad intent. It needs a task that is a little vague and a mode that does not ask. The damage is still real: a file changed outside the project is not in the project's history, so it is hard to review and hard to undo.

What does the new setting do?

When it is on, the three file-editing tools refuse paths outside the working directories. The changelog says this holds in every permission mode. If a task genuinely needs another folder, someone has to add that folder on purpose.

Several details are not in the changelog entry, and I could not find them elsewhere in Anthropic's documentation: whether the setting is on by default, how the refusal message reads, and whether a managed (organisation-wide) policy can force it on or off. Check the current settings reference before you roll it out.

Is there a similar setting for reading files?

Yes. permissions.blockReadsOutsideWorkingDirectories needs Claude Code 2.1.257 or later. Anthropic's settings reference describes it as making the file tools refuse reads outside the working directories in every permission mode.

Anthropic's page on settings files adds one useful detail about it. Normally a higher-level source, such as an organisation's managed settings, wins when the same key is set in two places. For this reading setting there is an exception: a true from any scope is honoured, even when a managed source sets false. In practice, a project can switch the block on for itself, and a lower-level file cannot undo it.

That is documented for the reading setting only. I found nothing saying the writing setting follows the same rule, so do not assume it does.

What does it not cover?

Terminal commands. The release note names three file tools. It says nothing about commands the agent runs in the terminal. A terminal command is a separate route, and it can in principle change files anywhere your account is allowed to write. Claude Code has a separate sandbox feature for limiting commands, which I did not test here. If you need a firm wall around commands as well, look at that.

Everything beyond files. The setting is about where files are written. It does not decide which websites the agent contacts, which tools it connects to, or what it may read. Those are separate controls, set through allow and deny rules.

So think of this as one fence around one gate. It is enforced by the tool, not by good manners, and that is its value. It is not the whole boundary.

What does this mean for a team?

Founders and product owners

You get a simple question for whoever sets up your AI tooling: "Can the agent change files outside our project folder?" For the file-editing tools, with this setting on, the answer is now no. For terminal commands, ask separately.

Managers and security-minded reviewers

The gain is largest where the agent works with few or no approval prompts, because there the setting is the only thing standing between a vague task and a stray edit. It is a rule the agent cannot argue its way past.

Testers and analysts

Expect "refused" messages in the first week. That is the setting working, but it can also catch legitimate work, such as a test that saves a report to a shared folder. Each refusal is a small decision: is this folder part of the project or not? Write the answers down.

Engineers and tech leads

Decide which file holds the setting. Anthropic's settings page describes four sources: a personal file in your home folder, a shared project file you commit, a personal per-project file, and managed settings from your organisation. A committed project file reaches everyone who clones the project. The personal files reach only you. Managed settings sit at the top of the precedence order. Some project-level entries, such as extra directories and allow rules, wait until each teammate has chosen to trust the folder, so check how a teammate's session actually behaves.

If you run several agent sessions at once, each in its own copy of the code, the working directory is that copy, so the fence is tight for each session.

How do you try it safely?

1. Pick one real task that you already know the agent can do, in a project that is not critical.
2. Turn the setting on in your personal or project settings. Claude Code reloads most settings edits without a restart, but starting a fresh session removes any doubt.
3. Run /status to confirm which settings files Claude Code loaded.
4. Run the task and note every refused path.
5. Decide per path. If the folder is truly part of the work, add it as an extra directory on purpose. If not, leave it blocked and have the agent do the job another way.
6. Roll it out to the team's shared settings once the refusals make sense.

The setting is new, so expect small fixes around it. The next release, 2.1.316 on 31 October 2026, fixed a separate problem in the same area: --restricted sessions uploading files from outside the working directories when a Read allow rule covered them. I could not find what --restricted does beyond that line, but it shows the boundaries around working directories are still being adjusted.

How does Atlas handle this?

Atlas runs each of its AI engineers as its own Claude Code session with its own working folder, so engineers do not edit the same files under each other. That is a separation of work, not the same as this setting. Atlas does not today switch on Claude Code's rule against writes outside the working directories. That is coming to Atlas, built in, so it needs no setup on your side. Until then, if you use Claude Code directly, you can add the setting to your own settings file. More about the team is on the Atlas home page.

Conclusion

The new setting is a small change with a clear purpose. It turns "keep the agent inside the project" from a hope into a rule that holds in every permission mode. It covers the file-editing tools, not terminal commands. Try it on one task, handle the first refusals deliberately, and then make it a team default.