# Claude Code 2.1.314 Closes a Managed-Policy Fail-Open and Adds a Switch That Blocks Writes Outside Working Directories

Claude Code 2.1.314 (30 October 2026) fixes a bug that let sessions start with no managed policy when the settings server was unreachable, closes a sandbox gap on resumed headless worktrees, and adds permissions.blockWritesOutsideWorkingDirectories. If you enforce policy through managed settings, update now.

By Neomanex. Updated 2026-10-31.

**Update now if your Claude Code guardrails live in managed settings.** Claude Code 2.1.314, dated 30 October 2026 in Anthropic's changelog, fixes a case where a session could start with no policy at all. It also closes three narrower gaps in the sandbox, hooks and settings sources, and adds the first setting that makes Claude's file tools refuse writes outside the working directories in every permission mode. Our Claude Code rating stays **conditional**: this is a routine hardening release, and the right response is to upgrade, not to rethink the tool.

## What happened

### The managed-policy fail-open

The changelog, verbatim: "Fixed `forceRemoteSettingsRefresh` set only in remote managed settings no longer applying once the stored copy had expired, which let sessions start without policy when the server could not be reached".

In practice: an organization that set `forceRemoteSettingsRefresh` only in its remote managed settings expected Claude Code to refuse to run unmanaged. Once the cached copy expired, that flag stopped applying, so a machine that could not reach the settings server started a session with no policy. Machines that never lost contact with the server were not exposed by this path.

### Three more permission and sandbox fixes

All verbatim from the 2.1.314 entry:

- "Fixed sandbox protections not applying to a worktree entered by `claude -p --resume` or `--continue`"
- "Fixed a settings file excluded with `--setting-sources` still supplying some settings, such as auto mode rules and saved permission consents"
- "Fixed hooks matching Bash not running on shell commands started by the Monitor tool; such hooks can block or ask, but not approve or rewrite those commands"

### New hardening switches

- "Added `permissions.blockWritesOutsideWorkingDirectories`: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode"
- "Changed Claude's file tools to ask before editing the local copy of your organization's server-managed settings, as they do for your settings files"
- "Changed flagged requests to retry on another model, not end in a refusal, when `ANTHROPIC_DEFAULT_OPUS_MODEL`, `availableModels` or `deniedModels` leaves only an older Opus model, or none"

The same entry adds idle compaction to VS Code and Claude Desktop's Code tab: "a 200K+ token conversation left idle is summarized, and the summary is used on your next message if the prompt cache has expired".

## Why it matters

The fail-open is the headline. `forceRemoteSettingsRefresh` exists so that a managed machine does not run without policy, and it failed in exactly the case it was meant for: an expired cache plus an unreachable server. Any deny rules, sandbox settings or model restrictions delivered through remote managed settings were absent from those sessions.

The other three fixes each remove a quiet bypass:

- **Resumed headless jobs.** Anyone who resumes `claude -p` jobs in sandboxed worktrees ran them without sandbox protections.
- **Excluded settings files.** A file excluded with `--setting-sources` could still carry auto mode rules and saved permission consents into a session.
- **Monitor tool commands.** Shell commands started by the Monitor tool skipped Bash hooks, so a blocking hook did not fire on them.

The new `permissions.blockWritesOutsideWorkingDirectories` setting covers Claude's file tools only (Write, Edit and NotebookEdit). The changelog does not say it applies to Bash, so a shell command can still write elsewhere unless the sandbox or a deny rule stops it.

## What changes for you

- **Managed fleets:** upgrade every machine to 2.1.314, starting with any that rely on `forceRemoteSettingsRefresh` to block sessions without policy.
- **Headless pipelines:** if you run `claude -p --resume` or `--continue` inside sandboxed worktrees, upgrade before the next run.
- **Unattended runs:** consider setting `permissions.blockWritesOutsideWorkingDirectories` in managed or project settings, and pair it with the sandbox or Bash deny rules, since it does not cover shell commands.
- **Teams using `--setting-sources`:** after upgrading, recheck which auto mode rules and saved permission consents still apply.

## What this does not tell you

The changelog names no CVE and links no advisory, so there is no official severity rating. There is no 2.1.313 entry: the changelog goes from 2.1.312 (27 October) straight to 2.1.314, and gives no reason. We have not tested 2.1.314 ourselves.

Canonical: https://neomanex.com/news/claude-code-2-1-314-managed-policy-fail-open-fix-sandbox-resume-block-writes