Claude Code 2.1.314 Blocks Writes Outside Your Working Directory

Anthropic released Claude Code 2.1.314 on October 30, 2026, adding a permissions.blockWritesOutsideWorkingDirectories setting that makes the Write, Edit and NotebookEdit tools refuse paths outside declared working directories even in bypassPermissions or dontAsk modes. The release also extends idle compaction to VS Code and the Claude Desktop Code tab, summarizing sessions past 200,000 tokens, and lets flagged requests retry on a different model rather than failing outright. The update includes 81 bug fixes and 16 other improvements.

Claude Code 2.1.314 shipped October 30 with a new permissions.blockWritesOutsideWorkingDirectories setting Idle compaction now reaches VS Code and the Claude Desktop Code tab, summarizing sessions past 200,000 tokens A flagged request now retries on a different model instead of ending in a flat refusal Cloud sessions start even when a setup script exits with an error, instead of failing outright Anthropic shipped Claude Code 2.1.314 on October 30, 2026. The headline for anyone running the tool solo isn't a new model, it's a setting you have to turn on yourself: a way to make Claude Code refuse to write outside your project folder no matter which permission mode you're in. The same release also brings idle compaction to VS Code and the Claude Desktop Code tab, so a long session doesn't just sit there bloating past its own context window. Neither change makes a splashy headline. Both are the kind of release that closes a door you didn't know was open. The new setting is permissions.blockWritesOutsideWorkingDirectories . Turn it on and the Write, Edit and NotebookEdit tools refuse any path outside your declared working directories, full stop, regardless of which permission mode the session is running in. That last part is the detail worth sitting with for a second: it applies even in bypassPermissions or dontAsk , the modes that exist specifically to skip the approval prompt entirely. Idle compaction is the other concrete addition. It's not new to Claude Code. The terminal has had a version of it for a while. What's new in 2.1.314 is that it reaches VS Code and the Code tab in Claude Desktop too. Leave a conversation sitting past 200,000 tokens and it gets summarized in the background. That summary gets used on your next message, but only if the prompt cache has already expired by the time you come back. The same release widens who gets idle compaction at all: it now runs for subscribers who've turned off telemetry, and on Bedrock, Vertex, Foundry and other LLM gateways once their one-hour prompt cache is switched on. A few smaller changes round things out. A flagged request, one that trips a safety check, now retries on a different model instead of just refusing outright. That only happens in the specific case where your model settings leave nothing but an older Opus model, or no fallback at all, to retry with. Cloud sessions now start even if their setup script exits with an error, rather than failing the whole session over a script that didn't need to be perfect to begin with. And git grep on macOS switched to the C locale across most commands Claude runs, which fixes a reported memory leak in macOS's own regex library. That last one is Apple's bug, not Anthropic's, but it's Anthropic's fix. The release notes list 81 bug fixes and 16 other improvements beyond what's summarized here. I didn't dig through all of them. A few other line items caught my eye on the way past: /permissions now refuses to let you approve a call you can't actually read in full, which closes a small trust gap in a workflow a lot of people click through too fast. The Bash tool's shell now clears any which alias or function it inherited, so which resolves to the real system command instead of whatever a dotfile happened to redefine it as. Small on their own. Together they're the shape of a release that's mostly maintenance with two real features riding on top. The four changes I'm covering in depth are the ones that actually change how the tool behaves under your hands. That's the bar I use for what's worth writing about at all, not whether a line sounds impressive in a changelog. Because permission modes were never really a write boundary. They were an approval boundary, and those are two different promises. acceptEdits skips confirmation for edits inside the session. bypassPermissions skips it for everything. Neither one, before this release, stopped Claude Code from touching a file outside the folder you opened it in, as long as your OS user had write access there. If you keep a second project, a dotfiles repo, or anything else writable sitting in your home directory, that was always technically in reach. Not likely to happen. Technically possible the whole time. Most of the time that's never been a real problem for me. I've run Claude Code in fairly loose modes for a while now specifically because the paths it touches have matched the paths I meant it to touch. But "usually fine" is a different claim from "actually bounded," and a setting like this exists to collapse those two sentences into one. It also plugs a gap I wrote about back when 2.1.285 shipped allowedProviders https://dev.to/blogs/lab/claude-code-2-1-285-what-allowedproviders-actually-locks-down . That release locked down which model providers a session could reach. It never touched the filesystem side of the same question. Which model, and which files, are both forms of the same boundary problem, and this is the filesystem half finally catching up to the provider half. I'd turn it on in any project directory shared with a teammate, a client, or anything running unattended in a cloud session. The cost is close to zero. A session that only ever meant to touch its own project folder loses nothing by being told it can't touch anything else, and gains a guarantee it didn't have an hour ago. This is also the kind of setting that matters most precisely when you're not watching. A session you're sitting in front of, you'd probably notice a stray edit to the wrong file pretty fast. A scheduled cloud session running overnight, committing on its own while you're asleep, is exactly the case where a boundary like this earns its keep. I run jobs like that, and this is the first setting I'm changing once this version lands. Mechanically, it's a background summarization step that fires when a conversation goes quiet past a size threshold. 200,000 tokens is a lot of back-and-forth. You get there on a long debugging session, or a big refactor where Claude keeps re-reading the same handful of files. That's a lot of tokens. Most sessions never get close. The part that actually matters is the timing condition. The summary only gets used on your next message if the prompt cache has already expired. Come back inside the cache window and you're still working off the full history, nothing changes for you. Idle compaction is specifically there for the session you walked away from for long enough that the cache cost would've reset anyway. It's not a general compression feature. It's a way to avoid paying for a fresh context load on exactly the sessions where you were already going to pay for one, and only on those. Narrow by design. That's the point. For anyone tracking Claude usage the way OhNine https://dev.to/blogs/lab/ohnine-why-i-built-a-menu-bar-app-for-claude-limits does, this is worth knowing about even if you never touch the setting yourself, because there's no setting to touch. A session that compacts itself while idle shows up differently in your usage pattern than one that just silently grows until it hits a wall. If you've noticed a long-running VS Code session feeling lighter after a break, this is probably why, not something you did. Yes. Not because of either feature above on its own, but because of the 81 bug fixes riding along with them. A changelog this size almost always carries at least one fix for something you've personally hit and quietly chalked up to bad luck. Past that, I'd prioritize the two changes by how much they cost to adopt. blockWritesOutsideWorkingDirectories costs you nothing to turn on and closes a real gap, so that one goes first. Idle compaction isn't something you configure at all. It's just there once you update, so there's no decision to make on that one beyond updating in the first place. The flagged-request retry change is the one I'd watch rather than celebrate. It only fires in a specific, narrow case: your model settings have nothing left to fall back to but an older Opus model, or nothing at all. That won't affect most setups. But if you've pinned your model list down tight for cost reasons, it's worth knowing a flagged request won't just dead-end the way it used to. It'll try something else first, quietly, before it gives up. None of this is a reason to hold off on anything you were already planning to ship this week. It's a reason to spend five minutes in your settings.json before you do. That five minutes is cheap insurance. I'd rather spend it now than explain later why a session wrote somewhere it shouldn't have. The setup-script fix is worth a mention too, even though it's the smallest of the four. Before this release, a cloud session could fail to start at all over a setup script that exited with a nonzero code, even when the script had already done its job and the failure was incidental, a package manager warning, a cache miss, something that didn't actually block the environment from being usable. Now the session starts anyway. If you've ever had a cloud routine refuse to boot for a reason that turned out to be cosmetic once you dug into the logs, this is the fix that stops that from happening again. 2.1.314 doesn't add a capability so much as it closes two small gaps that were already there. A permission mode that skipped approval but never bounded the filesystem. A long session that grew past its own usefulness without doing anything about it on its own. If you only make one change after reading this, add permissions.blockWritesOutsideWorkingDirectories to any project you run in a loose permission mode, especially a cloud session nobody's watching in real time. It costs nothing, and it's the kind of boundary you want in place before you need it, not after you've already found out the hard way.