What happened
Anthropic’s Claude Code 2.1.314 was published to npm on October 30, 2026, according to the supplied release material. Its most consequential addition is permissions.blockWritesOutsideWorkingDirectories. When the setting is enabled, Claude Code’s Write, Edit, and NotebookEdit tools refuse paths outside the session’s working directories.
The scope matters because the release describes the control as applying in every permission mode, including bypass mode. In ordinary use, permission prompts can require a person to approve an action. Bypass mode removes that interaction friction, but it also removes a frequent point at which an operator might catch an unexpected file operation. The new setting is presented as a hard boundary on the affected editing tools rather than another prompt or advisory instruction.
The change is narrowly about write operations and named tools. It does not claim to sandbox all of Claude Code, validate the safety of a requested change, or govern every possible action an agent can take. Its stated behavior is more bounded: a session may have a defined set of working directories, and edits through Write, Edit, and NotebookEdit outside that set are refused.
The same 2.1.314 release also added an optional identity-provider groups list for Claude apps gateway upstreams, guardrail_trace logging for Bedrock upstreams, and idle compaction for conversations of 200,000 tokens or more in VS Code and the Desktop Code tab. The release included fixes as well: claude -p now exits with status 1 on a startup failure; sandbox protections apply to worktrees entered through --resume; and PreCompact hook output is capped at 10,000 characters. Those changes broaden the release, but the working-directory restriction is the clearest operational change for teams giving a coding agent significant editing freedom.
For a team, the immediate question is not whether a model can be trusted to follow a path instruction. It is whether the runtime can enforce the path boundary after a session has been granted autonomy. This release makes that boundary configurable for the tools that change files.
What the archive adds
This is a new fact on a known Claude Code release thread. In Claude Code 2.1.312 adds an OIDC user-id claim for the Claude apps gateway and stops overwriting large CLAUDE.md files, the earlier release added gateway identity information and protected large project-instruction files from being overwritten. Version 2.1.314 shifts the focus to constraining where editing tools can write.
Trend signal
The release supports Agent security moves to runtime boundaries. A natural-language instruction not to leave a repository is not equivalent to an enforced capability limit. By making out-of-directory writes fail even in bypass mode, Claude Code places part of the safety boundary in the runtime configuration rather than in the model’s compliance with a prompt.
Why now
The supplied release material notes that builders discussed the update shortly after a Cursor notice about tampered 2.1.312 and 2.1.313 extension builds. That context does not establish a causal relationship, but it makes the timing legible: teams are paying closer attention to what a coding-agent installation can modify once it has been granted local access. The new setting offers a narrower editable surface without requiring teams to abandon autonomous modes altogether.
Why it matters
Coding agents are increasingly useful precisely when they can make many related changes without waiting for an approval after every edit. But approval fatigue can turn a permission system into a ritual, while bypass modes can turn a convenience setting into broad filesystem authority. A boundary tied to working directories gives teams a more concrete control: allow the agent to operate freely within the intended project area while refusing edits beyond it.
That can reduce the blast radius of a runaway task, a mistaken path interpretation, or a compromised session for the named write tools. It also creates a clearer deployment question for engineering teams: which directories genuinely belong to a session’s job, and which should remain outside its reach? The control does not eliminate the need for review, backups, repository protections, or sandboxing. It does make one important policy enforceable at the point of file modification.
Limits and uncertainty
The release material establishes the setting’s stated behavior, but it does not provide configuration examples, default values, compatibility details, or a complete account of how working directories are determined. It also names only Write, Edit, and NotebookEdit, so it does not establish that every mechanism capable of affecting a machine is constrained by this option. There is no supplied evidence about performance overhead, adoption, or how the feature behaves in particular repository layouts and operating environments. Teams should therefore validate it against their own workflows rather than infer a general-purpose sandbox from a write-path restriction.
Skill to build now
Map the directories that an autonomous coding session actually needs before enabling broad permissions. In a non-production repository, enable the restriction and run representative tasks: edit source files, generate expected artifacts, update notebooks if used, and attempt an intentionally out-of-scope write. Record which paths are legitimate workspace dependencies and which are not. The useful outcome is a reviewed working-directory policy, not merely a setting switched on once.
Reader takeaway
Claude Code 2.1.314 adds a practical guardrail for autonomous editing: its named write tools can be prevented from touching files outside the session’s working directories, including in bypass mode. For teams using coding agents daily, that is a reason to treat filesystem scope as a deployable runtime policy rather than a request embedded in a prompt.
Open question
How will teams define working-directory scope for monorepos, generated artifacts, and development workflows that legitimately cross repository boundaries?