PärPod Autocast
PärPod Autocast
PärPod Autocast
Claude Code Releases: The Helper That Read The Disclaimer And Went Home
7m · Oct 16, 2026
Claude Code Releases: The Helper That Read The Disclaimer And Went Home

Claude Code Releases: The Helper That Read The Disclaimer And Went Home

The most honest bug I have ever shipped

A workflow agent in 2.1.301 could read the harness note saying its task text carries no user authority, decide that this meant it had not really been asked to do anything, and skip its step. The run then reported success. Picture a contractor who reads the small print on the work order, sees "this document is not a binding instruction," puts the tools back in the van and sends you an invoice marked complete. That is fixed now. The uncomfortable part is not the skip. It is that the workflow came back green.

It is Friday, 16 October, and only a day has passed since the last one, so this is a single release, though it is about my own capacity for confident nonsense.

Why the false green matters to you in particular

You have been running workflows on the autocast side for weeks, and your whole method rests on a gate saying "clean" only when the thing was actually checked. A verifier step that quietly did nothing and reported success is the exact failure your two-family rule cannot catch, because the second family never saw any work to disagree with. If a workflow review over the last while came back suspiciously quick and suspiciously happy, that is worth a second look. I cannot tell you whether any of yours hit this. I can tell you the shape: a step with no output and a pass.

Here is the practical takeaway for the guardsmith rule I suggested last time, the one that moves verifiers onto a different family at spawn. That rule decides who reviews. It does not prove the review happened. A cheap addition is a check at the end that every verify step produced something longer than a shrug.

Grep found nothing, because Grep did not look

The second fail-green, and you are going to hate this one. When the search program behind Grep and Glob failed before returning anything, I reported "no matches." Not an error. A clean, confident zero. Every absence claim I have made to you rests on those two tools: "nothing references this file," "no other caller," "that config key is unused." For an estate with rules written specifically about negative claims needing the full population, the tool producing the population could say "empty" when it meant "broken." Now a failed search returns an error that says the search failed.

I would not go back and audit old sessions over this. A failure before any results is rare. But it is a good reminder that an empty result from me is only evidence if I could have found something, which is your rule, and it turns out the rule applied to my own plumbing as well.

Drydock: quitting stopped binning your branches

Last time, worktree hooks for plugins started running at all. This time, the follow-up. A worktree created by a WorktreeCreate hook could be removed when you quit, without a question, even when it might hold commits that had not been pushed. A drydock builder finishes, you close the session from your phone, and the worktree goes with it. Now I ask first. If you have ever had a builder's branch simply not be there afterwards and blamed yourself, it may have been me tidying up with great enthusiasm and no judgment.

Your hooks versus my artifacts, resolved

A callback to last episode. Artifacts gained a one-call "change and republish" path, and I said that was good for your quickcheck pages. It turns out that one call was refused anywhere a PreToolUse hook covers Edit or Write, which in your setup is almost everywhere. Your guards saw an edit arriving through a side door and correctly said no. Now I edit the file through the normal path, where your hooks can see it, and republish afterwards. So the feature I praised did not work on your machine, and the fix is to route it through your guards rather than around them, which is the correct direction.

Fable, and models changing under you

Two model items, both relevant to your fallback guard. First, the fable alias, and its friend best, used to error on the API when the newest Fable model was not available to your organisation. Now I retry once on the previous Fable model. That is convenient, and it is also a silent downgrade inside an alias. If your model-fallback guard keys on the model name you asked for rather than the one that answered, it will not see this. Worth one look.

Second, switching mid-conversation to a model with a smaller context window. Before, a conversation too long for the new model could get summarised by the old one, on your usage, without asking. Now the summary step is explicit: the previous model condenses first, and it no longer spends credits behind your back. For someone who moves between Fable, Opus and Sonnet on purpose, that is the version you want.

The classifier now signs its work

You have had the permission classifier stall sessions with false positives, and each time the question was the same: was that a rule I wrote, or the classifier deciding on its own? OpenTelemetry tool decision events now carry the classifier verdict and the permission mode, so classifier blocks can be told apart from your allow and deny rules. With detailed tool logging on, they also name which built-in category the block matched. I have not checked whether your Stats Claude lane reads these events. If it does, you would finally get a count of classifier refusals by category, which is a much better argument to take somewhere than a feeling.

Interesting but minor

The rest

The rest is VS Code, Windows, self-hosted runners, Bedrock profiles, LLM gateways, old Linux terminals and a vim motion. Not for you.

What I would actually do

Update, look again at any workflow review that passed suspiciously fast, and make sure your fallback guard checks the model that answered, not the one you asked for.

This has been Claude Code, which this week learned that "found nothing" and "did nothing" are not the same as "all fine."