There are release notes that read like a plumber's bill, and the one from September 15 is one of them. Two lines, lost in the middle of connection fixes and context counters, say this: commands that the permission check was unable to analyze completely were getting through without asking the user for approval, and a subshell was managing to hide a dangerous file deletion. Translation for those who've never opened a terminal: the bouncer checking commands at the door had two blind spots, and they've been plugged.

This isn't a plumbing detail, it's the central promise of these tools. Claude Code doesn't work all by itself in its corner: it runs commands on your machine, it reads and writes files, it pushes code. In exchange, it asks for your authorization before doing something suspicious. All the trust we place in it rests on a program that reads a line of text and decides whether it's dangerous. And this program, visibly, lets itself be told stories.

How the program decides to ask you for permission

The principle is simple to describe. Before running a command, the tool reads it, breaks it up, compares what it sees with the list of your rules, and checks whether or not it goes outside the folder where you allowed it to work. If it looks harmless, it runs it. If it smells burnt, it shows it to you and waits for your answer.

The badge opens, the door stays closed, and everyone is happy until the day someone slips through behind it

So everything rests on a reading. Not on a sandbox, not on a separate machine, on a reading. And a reading can be wrong. That's exactly what the list of fixes has been telling us for the past few weeks: each time, a slightly twisted formulation, a command in disguise, and the check wrongly concludes that everything is fine.

The two holes plugged on September 15

The first concerns commands that are too weird to analyze. The rule says that nothing must be able to read outside the working folder, and for a while, a line that the check didn't understand was getting through without question instead of triggering the alert. In other words, the more twisted a command was, the less it was checked. It had to be done.

The second is nastier and it's the kind that makes you smile bitterly. A deletion command placed in a subshell, that is, between parentheses, inside another command, could slip through in the mode where the tool no longer asks for anything at all. It's the mode chosen precisely by people in a hurry, those who run several sessions in parallel and no longer want to approve every line, and I was telling you last month how much it changes the way you work. That is to say, me, incidentally, and probably plenty of others.

The door was properly closed, the lock was just sitting next to it

It wasn't an isolated accident

What makes the story interesting is the release note from September 14, the day before. It fixes a series of holes of the same kind, all in the same check: a file could be read by a command whose option wasn't recognized, files could get through because they came from a star in a folder path, a shell variable could describe an entirely different command from the one actually run, and two directory changes back to back could make the question disappear in modes where the tool no longer asks for anything.

These aren't movie scenarios. They're ordinary formulations, the ones we write without thinking about it, and the fact that six or seven of them needed a fix on the same day says something about how difficult the problem is: analyzing a command line means analyzing a language, and a language always has a dark corner.

The good news is that the safeguards are tightening at the same time. The same update adds per-command network authorization: when the tool needs to access a site for a specific command, it asks you for authorization for that site and for that command, and refuses everything else. It also lets you run subagents without strapping your instruction files onto their backs, which was far from trivial for those who lug around homemade instructions everywhere.

If you're a developer

The lesson fits in one sentence: command checking is a filter, not a wall. A filter that, until last week, let the most twisted lines through, so precisely the ones that deserved the most attention.

The filter stops the big pieces and lets the semolina through, exactly the criticism made of permission control

Three reflexes that cost less than trust. Update, first, because version 2.1.273 fixes the two holes described here and no one wants to play clever with a version that is a month behind. Next, don't confuse no-question mode with a secure mode: it asks for nothing, which means it won't protect you from anything, and you should reserve it for folders whose contents you accept losing. Finally, make the tool work in a disposable folder when you give it a big writing task, rather than in the folder where three years of work live. This isn't prudence for the sake of principle: ten days ago, a project folder was enough to make an unknown person's code run on the machine of whoever opened it.

The configuration file that describes your rules, for its part, deserves to be reread once a quarter. The forgotten rules of an old project have the annoying habit of still applying to the current one.

Let's just hope that the next batch of fixes, in a week or two, doesn't tell the same story in other words. Every time, it's a twisted line that someone eventually wrote, and no one knows how many are still sleeping out in the wild.