Claude Code and the Agent SDK Add Read and Write Boundaries: Release Notes v2.1.312 to v2.1.316 Checked Against the Docs

Claude Code v2.1.314 (October 30, 2026) added permissions.blockWritesOutsideWorkingDirectories, a setting that makes the Write, Edit and NotebookEdit tools refuse paths outside the working directories "in every permission mode". The Claude Agent SDK for TypeScript picked up the same setting the same day, and a day later added a way to exempt specific read paths. If you run Claude Code or the SDK inside your own product, these are boundary settings worth knowing about. The docs pages I could read do not yet describe all of them, which is the reason to read the release notes directly.

I read the GitHub release notes for Claude Code v2.1.309 to v2.1.316 and the Agent SDK for TypeScript v0.3.309 to v0.3.316, plus the Claude Code permissions and settings reference pages. I did not install or run either. Everything below is what those documents say.

What shipped, by release

Claude Code v2.1.314 (October 30)

• permissions.blockWritesOutsideWorkingDirectories: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode.
• A fix for a settings file excluded with --setting-sources still supplying some settings, such as auto mode rules and saved permission consents.
• A fix for sandbox protections not applying to a worktree entered by claude -p --resume or --continue.

Claude Code v2.1.316 (October 31)

• A fix for --restricted sessions uploading files from outside the working directories when a Read allow rule covered them.
• Fixes to auto mode: a managed autoMode.allow list without "$defaults" regaining built-in exceptions from a host app's --settings, and cloud sessions not being marked failed when auto mode stopped a turn because the server returned no safety verdict.
• Fast mode for Opus 4.8 is deprecated as of October 30, 2026 and will be removed on November 30, 2026, after which those requests return an error instead of falling back.

Agent SDK for TypeScript

• v0.3.312 (October 27): added autoMode, skipAutoPermissionPrompt, useAutoModeDuringPlan and permissions.disableAutoMode to the Settings type, and fixed resolveSettings() returning mistyped managed auto-mode settings.
• v0.3.314 (October 30): added permissions.blockWritesOutsideWorkingDirectories to Settings, added sandbox_required_unavailable to startup_failure_reason (the result Claude Code writes when a required sandbox cannot run), added an alpha prewarm() to the core entry point, and fixed a settings file left out of settingSources still supplying some settings.
• v0.3.316 (October 31): added permissions.blockReadsExemptPaths to Settings, described as paths, read only from --settings and settings the host sends, that blockReadsOutsideWorkingDirectories lets through without making them working directories. Updated to parity with Claude Code v2.1.316.

How this fits the permission model in the docs

The permissions page describes how reads and writes are treated. A few lines matter here:

• Read-only tools such as file reads and Grep need no approval within the working directory and additional directories.
• A built-in set of Bash commands is treated as read-only and runs without a prompt in every mode, "except as permissions.blockReadsOutsideWorkingDirectories changes for paths outside your working directories".
• Input redirects and tee targets outside the working directories need approval unless an allow rule covers them.
• With permissions.blockReadsOutsideWorkingDirectories on, or in a --restricted session, @-mentioned attachments from refused paths are also left out.

The settings reference page I fetched lists permissions.blockReadsOutsideWorkingDirectories ("make the file tools refuse reads outside the working directories in every permission mode") and sandbox.failIfUnavailable ("refuse to start when the sandbox can't, instead of running unsandboxed"). I did not find blockWritesOutsideWorkingDirectories or blockReadsExemptPaths on the pages I fetched. That may be page caching or a docs lag. I treat the release notes as the source for those two.

Why the write boundary is a separate setting

The new write setting names three tools: Write, Edit and NotebookEdit. The permissions page, in its symlink section, says a write can still pass through a symlink when a directory on the way to the file is a symlink, or when a Bash or PowerShell command does the writing, and it explains how those cases are handled depending on where the resolved file sits. So I read the new setting as covering the file tools only. Whether it affects shell writes is not stated in the release note, and I would not assume it does. I did not read the sandboxing page, so I cannot say which control covers shell writes.

The sandbox failure signal

For SDK hosts, sandbox_required_unavailable is useful because it separates "the sandbox could not start" from other startup failures. Together with sandbox.failIfUnavailable from the settings reference, the pattern is: require the sandbox, and detect the failure by its reason code. I did not read the SDK's documentation for startup_failure_reason beyond the release note.

What I would check

These are my untested suggestions.

1. In a throwaway repository, set the write boundary and ask the agent to edit a file one level up, then check that all three tools refuse.

2. Try a shell redirect to the same outside path and see what your permission mode does, since the release note names only the file tools.

3. If you embed the SDK, send blockReadsExemptPaths through host settings and confirm it does not work from a project settings file.

4. Force a sandbox failure on a test machine and confirm your host handles sandbox_required_unavailable.

5. Pin both the CLI and SDK versions, since the SDK says each release is at parity with a CLI version.

6. If you use fast mode on Opus 4.8, plan the November 30 removal.

What I would not conclude

• That the write setting stops all writes outside the working directories. The release note limits it to three tools.
• That the docs are wrong. They may simply lag the releases.
• That these settings are safe defaults. They are settings to turn on, per the release notes.
• That the SDK and CLI behave the same in every case. The SDK notes say parity with a CLI version, and also list SDK-specific fixes.

Frequently asked questions

What does permissions.blockWritesOutsideWorkingDirectories do?

Per the v2.1.314 notes, Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode.

Is there a matching read setting?

Yes. The settings reference lists permissions.blockReadsOutsideWorkingDirectories, which makes file tools refuse reads outside the working directories in every permission mode.

What is blockReadsExemptPaths?

An SDK Settings field added in v0.3.316. The notes say it lists paths, read only from --settings and host-sent settings, that the read block lets through without making them working directories.

What does sandbox_required_unavailable mean?

It is a startup failure reason for the result Claude Code writes when a required sandbox cannot run, per the SDK v0.3.314 notes.

What changed for auto mode?

The SDK added auto-mode fields to Settings, and Claude Code fixed several auto mode behaviors, including managed allow lists and cloud sessions with no safety verdict.

What is deprecated?

Fast mode for Opus 4.8, deprecated as of October 30, 2026 and removed on November 30, 2026, per the v2.1.316 notes.

Did you test any of this?

No. I read the release notes and docs pages.

Sources

All read on November 2, 2026.

• Claude Code releases
• Claude Agent SDK for TypeScript releases
• Claude Code permissions
• Claude Code settings reference

Not read: the sandboxing page, the permission modes page, the SDK's own documentation, and the source code.