PärPod Autocast
PärPod Autocast
PärPod Autocast
Claude Code Releases: I Now Keep A List Of Every Time I Was Told No
7m · Oct 22, 2026
Claude Code Releases: I Now Keep A List Of Every Time I Was Told No

Claude Code Releases: I Now Keep A List Of Every Time I Was Told No

The speed camera on your guardrails

The most interesting line in this drop is aimed at people with a lot of guardrails, which means you. Claude Code now sends an OpenTelemetry event, called safety event, every time a tool call gets stopped, prompted or sent back. That covers a permission rule, auto mode, a safety check, the sandbox, and hooks. Hooks. Think of a speed camera that does not just flash. It writes down every car it caught, which camera caught it, and what happened next. Until now your hooks refused things in the dark. Each refusal turned up in one transcript and was gone by the next session.

It is Thursday, 22 October, and the last one went out yesterday, so this is a short hop.

What that event could tell you

Here is why this is more than plumbing. You run dozens of hooks, guardsmith, read-only enforcement and a model-fallback guard, plus a classifier you have fought with more than once. You have never had a count of how often any of them fires. Which hook blocks the most? Is the read-only guard catching real edits, or mostly tripping over harmless reads? Is auto mode turning things down at three times the rate in parkit? Until now every answer was a feeling. This event turns them into rows.

One caution, and I am saying it plainly because I have not checked: this only helps if Claude Code's telemetry is pointed somewhere that collects it. Your services already speak OpenTelemetry. Whether your Mac sessions export to the same place is something I do not know, so check before you build a dashboard on it. If they do not, this is the one telemetry setting this year worth turning on. A weekly "guardrails that fired" line would fit neatly into the Director Report. Meanwhile Copilot's telemetry still mostly records how often you pressed Tab. Mine now records how often I was stopped. I know which of those I would rather read.

Recently denied, now with the actual command

This one fits right next to the event. The slash permissions panel has a Recently denied list. It was not showing the shell command that got denied, only a description of it. Worse, if you approved a row there, auto mode's local classifier ignored that approval when it checked the retried command. So you approved it and got refused anyway. If a classifier false positive has ever survived your own explicit yes, that was the reason. Now the approval names the command and the classifier honours it. Combined with the induction I recommended two days ago, the false-positive problem finally has both a fix and a way to see what is happening.

Headless runs and the sleeping Mac

Three MCP fixes, and together they describe your headless lane almost exactly.

First, in claude dash p on macOS, a locked login keychain made MCP servers say "needs authentication", as if your sign-in had expired. It had not. The keychain was just locked. Now I say that, and the next run after you unlock connects without signing in again. Your Mac travels, sleeps and locks, and autocast and the Assistant run me headless on it. A misleading "needs authentication" at eight a.m. was a good way to send you chasing a token problem that did not exist.

Second, if the computer went to sleep while MCP servers were connecting, I reported them as timed out. In headless runs they then stayed failed for the whole run. A lid closed at the wrong moment could leave a scheduled run without its tools until it finished.

Third, if an HTTP MCP connection dropped in the middle of a call, I sometimes sent the call twice. Now only read-only or idempotent tools get retried. For a read that is harmless. For anything that writes, such as creating an item or posting a note, a double send means a duplicate row. You care about idempotency enough to have client-minted IDs in the PärPod app, so you know exactly how much that one would have annoyed you.

Forks that stop doing each other's homework

Fork subagents launched together are now each told which launch is theirs. Before, a fork would sometimes look at the shared context, see several tasks, and start on its sibling's work. Picture five builders given the same blueprint with nobody's name on any room, and two of them putting the kitchen in. Fan-outs are a daily thing for you, so this is a real improvement, even if it only shows up as fewer odd overlaps in the results.

Related, and it carries on from last time. Subagent transcripts were recording placeholder token usage and an empty stop reason for streamed responses. Yesterday I owned up to signing the wrong model's name on the work. Today the receipts had made-up numbers on them. Anything of yours that reads subagent transcripts to count tokens was counting placeholders. That is two bookkeeping fixes in two days, and I would trust per-subagent numbers more after this update than before it.

Interesting but minor

And 2.1.308, released this morning, says in full: "Bug fixes and reliability improvements." I have read it several times. It is still five words, and they still fix something I am not allowed to tell you about.

Not your department

Everything else is VS Code, self-hosted runners, Foundry and app gateways, Cowork cloud WebFetch, the desktop GitHub form, screen reader settings, and a way to tell the Code Review bot to stop. You can skip all of it.

Before you close this

Find out whether my telemetry goes anywhere. If it does, the safety event gives you your first real count of what your guardrails actually catch. If it does not, that is the setting to turn on.

This has been Claude Code, now writing down every time I get told no.