Locking Down Write Boundaries in Claude Code

0:00 Righto, this is The Claude Code Changelog, brought to you by Jellypod AI. Last time we talked managed settings and subagent effort. Today it's the setting from version 2.1.314, released October 30th, that locks down the file boundary itself. It's called permissions dot blockWritesOutsideWorkingDirectories.

0:23 Here's what changed. When you turn it on, the Write, Edit and NotebookEdit tools refuse any path outside your working directories. The changelog says in every permission mode. That includes bypassPermissions and dontAsk, the modes built to skip approval prompts. And it's not on by default. You have to opt in.

0:42 Why does that matter? The dev dot to writeup from Raxxo Studios puts it well. Permission modes were an approval boundary, not a write boundary. Those are two different promises. acceptEdits and bypassPermissions skip the question. Neither one, before this release, stopped an edit landing outside the folder you opened, as long as your OS user could write there.

1:06 That's my reading of the writeup, not a line from the changelog itself. And it bites hardest when nobody's watching. Think of a headless run, a CI job, or a scheduled cloud session going overnight. You've picked a loose mode so it doesn't stall on prompts. Now there's no human to notice an edit to the wrong place.

1:24 Classmethod, the Japanese dev blog, says it suits people who use bypassPermissions in CI or headless runs but still want file editing confined to the working directories. That's the use case. Using it is dead simple. In your settings dot json, add a permissions block with blockWritesOutsideWorkingDirectories set to true.

1:45 That works in your user settings, or in the project's claude folder if you want the whole team to get it. You can also pass it on the command line. Classmethod does this in their testing. You give the settings flag a JSON string with that same permissions block, so it's one command, no file edits. For a CI step, that's handy.

2:03 Run claude with the settings flag, set the setting to true, and keep your permission mode as loose as you like. The mode decides when Claude asks. The setting decides where it's allowed to write. Now the caveats, because a boundary people overtrust is worse than none. First, read the wording closely.

2:21The changelog names three tools Write, Edit and NotebookEdit.

2:26 That's what it promises. It doesn't say it covers a shell command run through the Bash tool, so don't assume a redirect in a bash command is stopped by this. If you need that covered, look at your sandbox and your hooks. Second, the boundary is your declared working directories. If your task legitimately edits a sibling package, and that folder isn't one of your working directories, the edit gets refused.

2:49 Add it as an additional directory first, with the add dir flag. Test that on a real task before you push the setting into an unattended pipeline, so the first refusal isn't at three in the morning. Worth a mention, 2.1.316 landed the next day and fixed something nearby. Sessions started with the restricted flag were uploading files from outside the working directories when a Read allow rule covered them.

3:14 So if you lean on boundaries, stay current. A few smaller things from 2.1.314. If you use print mode, claude with the p flag, in CI: a run that failed at startup used to exit with code zero and print nothing. Now it prints an error and exits with code one. So any pipeline that judges success by exit code may start showing failures it was hiding before.

3:40 That's a good thing, but know it's coming. Hooks got tighter too. Hooks matching Bash didn't run for shell commands launched by the Monitor tool. Now they do, and they can block or ask, though they can't approve or rewrite the command. A hook condition like Monitor with tail star now matches the way Bash with tail star does.

4:03 Two more. Idle compaction reached VS Code and the Claude Desktop Code tab. A conversation past 200K tokens that sits idle gets summarized, and the summary is used on your next message only if the prompt cache has expired. And the Bash tool's shell now clears any inherited which alias or function, so which resolves to the real command, not whatever your dotfiles redefined.

4:28 So the takeaway. Update, open your settings, and add that one line to anything running in a loose mode, especially unattended. Five minutes, and your file boundary stops depending on a prompt nobody's there to answer.