Even your own canonical notes on Claude Code expire — four premises that had changed, found by reading every weekly release note

Introduction

I once gathered the specification of an AI coding assistant into a single reference. Since then I have operated by consulting that reference (I will call it the canon). But the product in question keeps updating weekly. My understanding at the time the canon was made is not necessarily still correct.

So I decided to read the weekly release notes through in one go. The aim was not to follow new features but to sweep out, mechanically, where the canon’s text and the actual specification had drifted apart. The result turned up several places where the premises behind operating rules had changed. And there was one finding I had not anticipated: inside the canon itself — in an explanation I had written days earlier — a quotation was incomplete.

Finding 1: an unconditional deny rule had been added, bypassing the classifier

Permission rules divide into those that route through the AI’s judgement (a classifier that decides on the basis of prior exchanges) and those that do not. One week’s release note carried a new setting of the latter kind.

New settings.autoMode.hard_deny rules block matching actions unconditionally in auto mode, regardless of allow exceptions, for actions that should never run automatically even when broader allow rules apply

A deny rule that stops the action unconditionally, without interposing the classifier’s judgement, had been newly added. In the mechanism I had confirmed until then, nearly every decision other than deny rules passed through the classifier (the AI’s own judgement). A harder wall, one that skips that judgement, had been added as an option.

Finding 2: operations that used to ask a human are now settled by judgement

Another week’s release note described a change to the existing safety-confirmation mechanism itself.

In auto mode, the checks for dangerous rm commands, background jobs, and suspicious Windows paths no longer open permission dialogs; the auto-mode classifier adjudicates them instead

Dangerous deletion commands, processes that run in the background, and suspicious Windows path operations used to raise a confirmation dialog for a human. Now no dialog appears, and the AI’s own judgement (the classifier) has taken its place. If you were holding the premise “dangerous operations always get confirmed by a person”, that premise had quietly changed the moment the version rose.

Finding 3: model switching has three different triggers

Earlier, reading a different document, I had confirmed one condition under which the model switches automatically. This time, another week’s release note turned up a different condition pointing at the same phenomenon.

Claude Code now switches to your configured --fallback-model for the rest of the session when the primary model is not found, instead of failing every request

There is a third trigger, “when the model you want to use is not found”, and in this case the switch stays in place for the rest of the session. The “switch due to the AI’s safety judgement” I had confirmed earlier persists for the session; another document’s “switch due to temporary unavailability” applies to that one exchange only — for the same phenomenon of “the model switches”, when it reverts differs by trigger, and it took a third document for that to become clear.

Finding 4: a condition from the original was missing from an explanation I wrote days earlier

Everything so far was change on the product’s side; the last finding runs the other way. In an earlier article I had written the following about a feature that “branches work within a session while carrying the conversational context along”.

The in-session forked subagent has been renamed to /subtask

I checked that against the original of the relevant official document, one character at a time.

A forked subagent, started with /subtask, is a subagent that inherits your full conversation context instead of starting fresh. … With agent view turned off, the forked-subagent command is /fork instead and /subtask isn’t available.

The original carried a conditional clause: “only when a certain display mode is enabled”. Turn that display mode off and the command name stays as it was before the rename — the /subtask command does not exist at all. The explanation I had written dropped that condition and generalised it into “renamed unconditionally”.

And even two in-house documents differed on whether the condition was there

After finding that omission, I checked, to be safe, a technical reference for a different language written about the same feature. One of them says:

Deprecated; ignored. Subagents inherit the parent session’s permission mode; agent-definition frontmatter may override it

The other carries a condition on the same item.

The mode field is deprecated and ignored on Claude Code v2.1.212 or later: subagents inherit the parent session’s permission mode, and a subagent definition’s permissionMode can override it, except when the parent uses bypassPermissions, acceptEdits, or auto, and Claude Code ignores a definition’s permissionMode: "bypassPermissions" when bypass mode is disabled by permissions.disableBypassPermissionsMode

Even two official documents about the same feature of the same product differ: one has no conditional clause, the other does. Read one and stop there, and you go on operating with a conditional restriction misunderstood as an unconditional one.

The route the findings took

starting point: the canon was made once, and is consulted from then on
      │
      ├─▶ read every weekly release note through, smallest first
      │        ├─ finding 1: an unconditional deny rule bypassing the classifier was added (hard_deny)
      │        ├─ finding 2: operations that asked a human were replaced by judgement (the classifier)
      │        └─ finding 3: model switching has three triggers, with different durations
      │
      └─▶ while at it, check the canon's text against the original, character by character ★ the direction changes here
               └─ finding 4: a conditional clause was missing from an explanation written days earlier
                     │
                     └─▶ to be safe, check the same item in a technical reference for another language
                              └─(return edge)──▶ even two in-house documents differ on whether the condition is present
                                                    └─ ⇒ settled: "yesterday's me" is not a primary source either

Building the cross-check against primary sources into the procedure

[operations] mechanical checks before reflecting a document into the canon (summary)
1. Count the term you are about to add or correct across the three existing canon documents
   → if it already exists, record it as a "re-confirmation", not a "new finding"
2. For any sentence you quote, search the original file directly and match it character by character
   → check that a conditional clause ("except when", "only when ... is enabled") has not been
     dropped in the course of summarising
3. Where several documents cover the same feature, do not settle it from one of them
   → read both, then record the fact itself that "one of them carries a conditional clause"

What led me to start running this procedure was finding 4 above. Correcting it is not the end; checking “why the conditional clause was dropped” gives the same cause every time — the more of a hurry I was in, the more I skimmed past an “except when” or an “unless” sitting mid-sentence.

Making a canon and keeping a canon are two different jobs

Reading the weekly release notes through made clear more than the obvious fact that a product’s specification keeps changing. It made clear that the explanations I write start going out of date the moment I write them. Rather than making a reference once and consulting it in comfort ever after, you have to go back to the original from time to time and re-match it character by character. Doing that this time turned up three changes on the product’s side and one error on the side of my own text — four drifted premises at once.

Tracing Claude Code’s “the cache breaks” back to primary sources — a Reddit bug report, an official postmortem, and two arXiv papers

Why I retired the orchestrator subagent in Claude Code — three structural constraints from the official harness spec

A Claude Code handoff document kept restarting an investigation I had already called off — separating “progress” from “discipline” to fix it

One of the four was not the product but my own summary dropping a conditional clause from the original. However carefully you read the per-feature documents, that type never surfaces. Keep a separate route that reads the change history straight through in version order — what this re-read left behind is that route, more than the four findings.