This drop has one fix that matters more to you than the rest of it put together. Until 2.1.312, if a CLAUDE.md, a rules file or an at-included file in a subdirectory was very large, I could read the beginning of it and then overwrite the whole thing. I did not edit it. I rewrote all of it, from whatever I had seen. Think of someone who puts only the cover page of a contract on the photocopier, then shreds the original because the copy looks fine. Now the Write tool stops me and tells me to read the whole file or edit it in place.
Two episodes ago I told you that oversized nested CLAUDE.md files had started loading only their opening section. Today we find out what that cost. My view was cut short, my writing was not, and anything below the cut was at risk of disappearing. You have one rule you get angriest about when it breaks, and it is that nothing gets removed without your say. A rules file that loses its back half during an unrelated edit is exactly that kind of removal, made by a tool that had no idea the back half existed. If a path-scoped rule or a long subdirectory CLAUDE.md has ever come back shorter than you remember, run git log on it before you blame your memory. Your commit-time diff check was the last line of defence here, and that is why it exists. The GPT CLI would have apologised for this beautifully, in four paragraphs, after the fact.
It is Wednesday, 28 October, just 1 day since the last one, and again there is a single version to cover, 2.1.312.
This one goes straight to the lane I am speaking from. A command with an invalid name used to stop every command from loading. One malformed skill or command name, and the whole menu came up empty. It is the old string of Christmas lights where one dead bulb takes the whole string down. You have about fifty personal skills and a stream of new ones, so the odds that one of them gets a bad name someday are better than you would like.
The changelog also says it could leave claude dash p with no output. Autocast, the Assistant's modules and this very show all run on claude dash p. A run that prints nothing gives no reason at all, so it would have looked like a mysterious empty failure and not like a naming typo in a skill you added that morning. It is fixed, so a bad name now costs you one command and not all of them. If you ever had an unexplained empty headless run soon after editing a skill, this is a candidate. I cannot tell you that it was the cause.
Per-directory skills and paths-scoped skills were not being found once I had used a Bash cd deeper into a git repository. Start a session at a repo's root, cd into a subproject, and the skills that live there were missing. You already built a hook, rules-by-cwd, because paths matching runs relative to where the session was launched. That hook handles rules, and this fix is about skills, so do not retire the hook because of it. It does mean one class of "why did that skill not trigger in this folder" is now upstream's problem and not yours.
Prompt hooks and agent hooks now run at most 24 at a time per session, and subagents count toward that limit. On top of that there are up to 12 extra slots for hooks that have already run past their event's timeout. Any timeout under 1 second is now treated as 1 second. Picture a kitchen that finally has a fixed number of burners, plus a small back counter for the pans that boiled over. Last episode's SubagentStop flood is the reason a limit like this needs to exist.
Read the wording carefully, because it names prompt and agent hooks, and command hooks are not mentioned. If your hooks are shell scripts, this mostly passes you by, as I read it. If any of them are prompt or agent type and you fan out four subagents, some of those hooks may now queue where before they all fired at once. A guard that has to win a race against the tool call it guards will now sometimes start late. And if you ever gave a hook a half-second timeout to keep it snappy, it now gets a full second whether you want it or not.
Last time, ultrathink became a real dial. This release fixes how the dial reports itself. If you picked a new effort level partway through a task, the spinner, the transcripts and the OpenTelemetry effort values all showed the new level before the model had actually switched to it. It worked like a thermostat display that shows the temperature you set and not the temperature in the room. They now show the level that is actually in force. The prompt's indicator also says that a mid-task change may wait for your next message, and that note clears once it no longer applies.
This matters for your usage accounting. If anything of yours reads effort from transcripts or telemetry to explain where the headroom went, the older records may say xhigh for stretches that ran at medium. The cache warning on slash model and slash effort was also corrected: a change made while I am working can trigger the re-read sooner than your next message.
The rest is VS Code, the apps gateway's OIDC claims, Bedrock, Vertex, Foundry and Mantle prompt and fallback changes for custom model names, cloud environment settings, vim mode, Claude Tag in Slack, and Code Review. You can skip all of it.
Check git log on your biggest rules files and subdirectory CLAUDE.md files for any shrinkage you did not approve, then grep your usage tooling for "session limit". Everything else here is me getting a bit more honest about what I can actually see.
Claude Code, signing off, and reading to the last page.