Claude Code update strategy, without your workflow suddenly breaking
In April 2026 Anthropic published a postmortem on a quality regression. Here are 10 steps to roll in updates so your workflow doesn't suddenly get worse, with pinning, an eval set and a rollback path.
On April 23, 2026, Anthropic published a postmortem. A verbosity reduction in the system prompt of Claude Code had measurably worsened code quality for some users. Since then Anthropic has been introducing per-model evals for every prompt change. On Reddit (r/Anthropic, 125 upvotes) and Hacker News (47878905) this was the top topic for days. The important lesson: you need your own update strategy, because "install the latest update and hope" no longer cuts it.
This playbook brings 10 steps for update hygiene for Claude Code, Cursor and Codex. You learn how to pin a version, how to build your own eval set, how to tell after an update whether the quality is stable, and how to roll back without drama.
I assume Claude Code, but the pattern carries over 1:1 to other tools.
Step 1, find out the current version and write it down
Run claude --version in the terminal. You get something like 2.1.x. Write that into a CLAUDE_VERSION.md in your main project with the date next to it. Sounds simple, but it is worth gold when after three weeks "something is different" and you want to know since when.
With Codex this goes via codex --version, with Cursor the version is under Help → About. There too: write it down.
Step 2, turn off auto-update
By default Claude Code updates itself on start. That is convenient but treacherous. If Anthropic pushes a build that causes problems for you, you had no choice. Turn it off in ~/.claude/config.json with "autoUpdate": false.
Instead you update when you have time. Sunday morning is good. Then you have the whole day to test without a live task waiting on it.
Step 3, read the release notes (really)
Anthropic publishes releases on github.com/anthropics/claude-code/releases. Before the update, scroll through once. Three things you look for: breaking changes (even if they are not called that), new features that affect you, bug fixes for bugs you reported yourself.
Updates can be massive. A single patch bump can bring 50+ changes, new slash commands, config migrations, edge-case fixes. What does not affect you directly (for example a Bun fix when you don't use Bun at all), you skim. What touches your workflow, you read carefully.
External source as a backup: claudelog.com/claude-code-changelog/ aggregates the releases with better readability than the GitHub format.
Step 4, set up an eval set
This is the most important step. You need a small list of 5 to 10 typical tasks that you do regularly with Claude Code. For me those are: "write a Prisma migration script", "review this pull request for security bugs", "build me a simple Express endpoint with validation", "fix this TypeScript type error".
Write each task into its own file evals/01-prisma-migration.md, with the concrete prompt and the expected solution. That is your benchmark.
Anyone without an eval notices a quality regression only when a real customer job goes wrong. That is too late.
Step 5, run the pre-update baseline
Before you update, go through the eval set once completely. Save the outputs in evals/baselines/<your-current-version>/ (for example evals/baselines/2.1.x/). Per eval the answer, the token count, whether the solution worked (you as a human decide), and subjectively how good.
This takes 30 minutes. You don't do it often, but once you have it, you have it.
Step 6, install the update
Now finally the update. With Claude Code claude update or npm install -g @anthropic-ai/claude-code@latest depending on the installation path. With Codex codex update. With Cursor via its own update system.
Right after the update again claude --version and add to CLAUDE_VERSION.md. Date, old version, new version.
Step 7, run the post-update eval
Exactly the same eval set as in step 5. Save the outputs in evals/baselines/<new-version>/. Compare.
You watch for three things. First, does the solution still work (binary). Second, has the answer become shorter/longer, and is that good or bad (see the April postmortem, verbosity reduction was negative). Third, has the style changed in a way you don't like.
If everything is better or equal: carry on. If something is worse: step 8.
Step 8, rollback path
Anthropic keeps publishing old versions on npm. You can go back to an old version with npm install -g @anthropic-ai/claude-code@<previous-version> (for example @2.1.142 if you updated to 2.1.143). Always note before the update which version you have (see step 1), then the rollback is a matter of 30 seconds.
If the problem really is the update, write an issue on github.com/anthropics/claude-code/issues. With eval input, old answer, new answer. Anthropic reacts to well-documented reports, especially after the postmortem.
Step 9, bring the rest of the world along
If your update ran clean, there is one more layer. Hooks, skills, MCP servers. Some break with newer Claude Code versions because APIs have changed. After every update, check whether your most important hooks still run (for example with a claude hooks list), and whether your MCP servers still connect (claude mcp list).
If an MCP server no longer connects, look in its issues whether this is a known conflict. Sometimes a simple npm update -g <mcp-server> helps. Sometimes wait until the maintainer reacts.
Step 10, find your update frequency
My own rhythm. Patch releases (for example 2.1.x → 2.1.x+1) I often skip for a week until I see whether someone complains on Reddit or in the Anthropic Discord. Minor releases (2.0 → 2.1) I update on the weekend with a complete eval run. Major releases (1.x → 2.x) I plan deliberately, read the migration doc, and take half a day.
The lever is not "be fast", the lever is "know what has changed". With an eval set and version pinning an update costs you 45 minutes and gives you confidence. Without discipline a failed update costs you a whole working day and the trust in the tool.
What comes next
If you don't have hooks yet, lesson L4-04 "Hooks und Skills" plus the playbook "Hooks gegen Halluzinationen". If you want to go deeper into eval-driven development, lesson L2-06 "Capstone" plus the L5 lessons on multi-agent reviews. For the general MCP server update loop see the playbook "MCP-Server publishen" which also discusses versioning.
Sources: Anthropic Postmortem 23.04.2026 (anthropic.com/engineering/april-23-postmortem), r/Anthropic discussion 125 upvotes, HN 47878905, claude-code Releases on GitHub, claudelog.com changelog aggregator.