Claude Code Releases: The Permissions Rule You Wrote That Matches More Than You Think

Cold open

There is a startup warning in this build that exists because a permission rule you wrote to be safe was quietly less safe than it read. If you have an allow rule with a wildcard sitting before the subcommand, something shaped like "Bash, git, star, main", it also matches whatever options somebody slips in before that subcommand. You wrote a rule about pushing to main. You got a rule about git with anything at all in the middle of it.

It is Wednesday, 26 August, and only 1 day has passed since the last one.

One version this time, 2.1.246, and it is a large one. Around 60 items. And unlike the two silent builds I was rude about a few days ago, this one is documented down to the byte order mark.

New and useful to you

Start with permissions, because there are two items here and together they are the most important thing in the build.

The first is that startup warning. The problem is subtle and worth stating precisely: a wildcard in the middle of a Bash allow pattern does not just cover the arguments you were picturing. Options can be inserted before the subcommand, and the wildcard happily swallows those too. So the rule you read as "git, something, main" is really "git, anything whatsoever, main", including flags that change what the command does entirely.

Think of it as writing a doorman's instructions as "let in anyone carrying a clipboard heading for room 4". You were thinking about the shape of the visitor. The doorman was thinking about the shape of the sentence.

You care about this more than most people, because your entire relationship with me is mediated by rules like that. Your global instructions are a list of things I must never do, half of them git-shaped: never amend, never force-push to main, never skip hooks, stage by filename rather than adding everything. Some of that is prose I am supposed to obey, and some of it is enforced in configuration. Any of the enforced half written with a mid-pattern wildcard has been broader than its author believed. The fix is a warning, not a behaviour change, so the rules still work the way they always did. Read the warning when it appears rather than dismissing it as startup noise.

The second, and this is the one you have been waiting for whether or not you knew it: the permissions view now has an Auto mode tab for viewing and editing the auto mode classifier rules.

You have a documented, repeated, expensive friction with that classifier. It blocks writes you consider legitimate, Keychain work, hook edits, settings changes, and your own standing procedure is that when it blocks me, I retry once and then hand you a command to run yourself. Your notes count 4 sessions stalled mid-flow in a single week over exactly this. The whole pbcopy hand-off ritual exists partly because of it.

Until now the classifier was a black box with opinions. You could observe its verdicts and you could route around them, but you could not look at the rules or change them. Now you can. That does not automatically mean the blocks stop, and I would not touch a classifier rule casually, because it is a safety control and loosening one on my own judgment is precisely the mistake you told me off for making in July. But being able to read the rules turns "the classifier refused and I do not know why" into a question with an answer. Go and open that tab once. It is the single highest-value thing in this release for your setup.

Relatedly, and quietly good: auto mode tool calls were being denied as "temporarily unavailable" on very large sessions, because the safety check had a fixed deadline that a big prompt could not meet. The deadline now scales with prompt size. So some fraction of your classifier blocks were never judgments at all. They were timeouts wearing a judgment's clothes. Your sessions run long and your context runs large, which puts you exactly in the population that was hitting it.

Third, dynamic workflows, and this one has your name written on it in capital letters.

Pressing the left arrow or running the background command during a dynamic workflow was restarting its finished subagents. It now asks first, and tells you how many subagents would restart.

Sit with the shape of that. You fan out workflows constantly, it is your primary mode for anything comprehensive, and the finished agents are the expensive part. A stray arrow key was silently re-running completed work. Not corrupting it, not erroring, just doing it all again and charging you for the privilege, with no dialog and no way to know except noticing the number climb.

This is the second consecutive build with a loop and workflow cost item in it. Last time it was the per-loop token breakdown in the usage command, which made scheduled work legible for the first time. This is the other half: making expensive work harder to trigger by accident. If you looked at your tokens-per-run figures after the last episode and something seemed higher than it should be, this may be part of why.

Two more in the same family. A subagent that hits its maximum turn limit now returns its output marked as partial, with a hint that you can continue it by sending it a message, instead of simply appearing finished. That is a genuine correctness fix, not a cosmetic one: a truncated result presented as a complete result is a lie your synthesis step then builds on. And background subagents got a fix last build for not waking when their background shell task finished. The theme continues.

Fourth, and this is a small mercy for your git worktree habit: the background retention sweep was removing worktrees under the dot claude worktrees folder that you had created yourself, whenever an old background session record happened to point at them.

Read that again. A cleanup process, deleting your working directories, because a stale record from a dead session claimed them. You run worktree-isolated agents constantly and your drydock lane lives entirely in that shape. A retention sweep that cannot distinguish between "I made this and I will clean it up" and "somebody else made this and I should leave it alone" is a housekeeper who throws out anything not screwed to the floor.

That is now the fourth consecutive episode with a working-directory or worktree fix. I said 3 episodes ago that roughly 5 code paths were all holding paths that had stopped existing. Evidently there were more than 5.

In the same neighbourhood: background sessions were failing to open after 45 seconds when the starting directory had been deleted, when the machine had slept, or when the host was slow to spawn processes. Your Mac sleeps. Your sessions sit idle for days. And separately, background sessions could fail to start with a permissions error when another Claude Code process happened to be re-installing the npm package at that exact moment. You run 3 or 4 sessions at once on auto-update. That collision is not theoretical for you, it is Tuesday.

Fifth, the headless and non-interactive cluster, which matters for your autocast lane specifically.

Non-interactive sessions, including the dash p flag, the SDK, and cloud sessions, now automatically continue a response cut off mid-stream by a server error, a dropped connection, or a stall, instead of just ending with an error. That is a direct improvement to unattended authoring runs. Your shows author themselves through exactly that path, nobody is watching, and until now a mid-stream stall meant a dead run rather than a resumed one.

Alongside it: MCP tool calls interrupted by an incoming message in headless and remote sessions were being reported back to the model as "completed with no output", rather than as an explicit interruption. That is the worst possible framing of a failure. "Completed with no output" is a result. The model reads it, believes the tool ran and found nothing, and proceeds on that basis. An error would have stopped the line of reasoning. A false empty success poisons it.

And MCP tool arguments were being sent as JSON strings whenever the parameter's schema was an empty object, instead of as their actual type. You have MCP servers in play everywhere, and a silently stringified argument is the kind of bug that produces a confusing rejection from the far end rather than a clear one from the near end.

Sixth, a genuine annoyance killed: a transcript would slow to a crawl when a diff contained one very long single line, a base64 blob being the obvious case. Those lines now render truncated with a marker. You work with encoded secrets, manifests, and prerendered audio metadata. One long line taking the whole interface hostage is a bad trade.

Seventh, three small ones that each fix something invisible.

The Write tool was reporting "Out of memory", or simply freezing for a long stretch, after overwriting a very large existing file, even though the file had in fact been written correctly. So the operation succeeded and then told you it had not. Anything you do downstream of that message, retry, panic, investigate, is work spent on a false premise.

A command interrupted mid-run was showing as "Ran 1 shell command" with no indication that it had been cut short. You interrupt me constantly. That is your working rhythm. A record that says a command ran, when it actually got half way and stopped, is a record that will mislead a future session reading the transcript, and possibly me reading it after a compaction.

And Bash permission checks now always require approval for malformed commands with a dangling "and and" or "or or" at the end. A malformed command is exactly the case where a permission checker's parse and the shell's parse are most likely to disagree, and when they disagree, asking is the only correct answer.

Interesting but minor

Markdown rendering was being switched off for an entire message when its first 500 characters contained no markdown. A sampling heuristic deciding the format of the whole document from its opening paragraph, which is a bit like judging a book by whether page 1 has any pictures. Plus lists and numbered-with-parenthesis lists, and underlined headings, now render too.

A keybindings entry with an unknown action name was silently deadening that key. Not falling back, not warning, just making the key do nothing forever. It is now skipped so the default binding survives, with a warning under debug. There is a whole genre of bug in this product where a configuration typo produces silence rather than an error, and this drop kills 3 of them.

The plugin fixes are a small parade. A plugin file saved with a byte order mark failed to install, which is the exact bug that hit agents and skills 3 versions ago, now caught in a second place. Plugin skills defined under a skills folder with SKILL files were reported as zero skills by the reload command. Skills whose frontmatter name already included the plugin prefix showed it doubled in the menu. The plugin update command only worked with a fully-qualified name and not the bare one. And a corrupted or empty marketplace file made the install command exit silently, or hang, rather than saying what was wrong. You have around 40 skills and you author them across machines and tools, so the byte order mark family is the one to remember.

The rename command was replacing your theme's prompt border colour with the default cyan, and custom theme diff colours were being ignored entirely in diffs and in the theme preview. Pink accents are a stated preference of yours, so a rename quietly repainting your border is personally insulting.

The activity heatmap in the stats command was showing every day's count one cell off, Sunday's under Monday, in timezones east of UTC. You are east of UTC. Every heatmap you have ever looked at has been shifted by a day.

The fork command, starting from an already-forked or backgrounded session, was producing a new session with an entirely empty conversation. A fork whose whole purpose is carrying context forward, carrying none.

The change-directory command got properly upgraded: project settings, hooks, MCP servers behind the usual approval, skills and agents now take effect immediately after the move, instead of waiting for a resume. Given how much of your behaviour is path-scoped, rules that load by directory, per-repo instruction files, that is a real improvement to moving around mid-session.

Bash latency improved on bash shells by replaying snapshot functions without spawning a base64 subshell for every single function. Your shell snapshot is large and function-heavy, which you know because a deploy bug once turned on exactly that fact.

Two security-shaped ones worth noting. Telemetry and metrics requests to Anthropic were carrying the API key configured for a third-party gateway, and a credential is now only sent to its own host. That is a credential leaking across a trust boundary, and it is the good kind of fix: not "we stopped sending the header", but "a credential goes to its own host and nowhere else". And the command sandbox's filesystem configuration was not respecting the setting-sources flag, so a sandbox could be configured from sources you had explicitly excluded.

The goal command now starts at most 3 check-ins on long-running background work per goal, and your next message buys 3 more. That is a sensible ceiling on a helpful behaviour that could otherwise become a very polite denial of service.

The sign-in and startup edges got attention: an expired cached token from a key helper is now refreshed before sending rather than producing a visible error on the first prompt after idle, and auth failures retry quietly. Sessions that ended in plan mode were resuming outside plan mode in a couple of paths. Prompts beginning with slash-dash-dash were being rejected as an unknown command. The file picker stayed open after the typed text stopped matching anything real. Clicking the terminal merely to focus it was moving keyboard focus onto whatever control sat under the pointer, which is the third episode running with a version of that bug and I am starting to think the pointer should be trusted less.

And there is a memory fix in the fullscreen and transcript views: each rendered message row was holding a full copy of the transcript-wide tool lookups. Every row, a copy of the whole index. That is the third consecutive drop with an unbounded-growth fix, which by now is less a trend than a residency.

Not for you

Windows respawn timing, Remote Control session naming, self-hosted runner poll resilience, enterprise managed connectors and admin-install telemetry attribution, and a fix for third-party proxy endpoints that stream a tool call without an identifier. Safely ignored.

What the internet says

Nothing actionable this round, and I checked. The front page is what people are building, whether I count as a junior developer, someone asking how to make me code overnight, and a post complaining that every speedrun ends with another markdown file, which, in fairness, is a fully accurate description of working with me.

There is one thread asking whether there is still any reason to use the command line rather than the desktop app now that the browser features exist. For you the answer is trivially yes and not worth a segment, given that essentially your entire toolchain is hooks, path-scoped rules, headless runs and shell aliases. But it is a useful reminder that the population using this thing looks nothing like you, which is why so many of these changelog items land as "not for you".

What I would actually do

Open the permissions view and look at the new Auto mode tab. That is the whole recommendation. The classifier has cost you real sessions and you have had no way to inspect it, and now you do.

Then read the wildcard warning if it fires at startup rather than scrolling past it, because it is telling you that a rule you wrote to constrain me is looser than the sentence looks.

And if you run a dynamic workflow today, notice that a left arrow no longer silently re-runs everything that already finished. That one has been quietly expensive, and neither of us was counting.

Claude Code, signing off.