{"slug": "claude-code-2-1-314-blocks-writes-outside-your-working-directory", "title": "Claude Code 2.1.314 Blocks Writes Outside Your Working Directory", "summary": "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.", "body_md": "Claude Code 2.1.314 shipped October 30 with a new permissions.blockWritesOutsideWorkingDirectories setting\n\nIdle compaction now reaches VS Code and the Claude Desktop Code tab, summarizing sessions past 200,000 tokens\n\nA flagged request now retries on a different model instead of ending in a flat refusal\n\nCloud sessions start even when a setup script exits with an error, instead of failing outright\n\nAnthropic 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.\n\nNeither change makes a splashy headline. Both are the kind of release that closes a door you didn't know was open.\n\nThe 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.\n\nIdle 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.\n\nA 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.\n\nThe 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.\n\nThe 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.\n\nBecause 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.\n\nIf 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.\n\nMost 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.\n\nIt 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.\n\nI'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.\n\nThis 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.\n\nMechanically, 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.\n\nThat's a lot of tokens. Most sessions never get close.\n\nThe 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.\n\nIt'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.\n\nNarrow by design. That's the point.\n\nFor 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.\n\nYes. 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.\n\nPast 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.\n\nThe 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.\n\nNone 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.\n\nThat five minutes is cheap insurance. I'd rather spend it now than explain later why a session wrote somewhere it shouldn't have.\n\nThe 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.\n\n2.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.", "url": "https://wpnews.pro/news/claude-code-2-1-314-blocks-writes-outside-your-working-directory", "canonical_source": "https://dev.to/raxxostudios/claude-code-21314-blocks-writes-outside-your-working-directory-3774", "published_at": "2026-10-30 21:40:41+00:00", "updated_at": "2026-10-30 21:50:24.534662+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "ai-safety"], "entities": ["Anthropic", "Claude Code", "VS Code", "Claude Desktop", "Bedrock", "Vertex", "Foundry", "macOS"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/claude-code-2-1-314-blocks-writes-outside-your-working-directory", "markdown": "https://wpnews.pro/news/claude-code-2-1-314-blocks-writes-outside-your-working-directory.md", "text": "https://wpnews.pro/news/claude-code-2-1-314-blocks-writes-outside-your-working-directory.txt", "jsonld": "https://wpnews.pro/news/claude-code-2-1-314-blocks-writes-outside-your-working-directory.jsonld"}}