Two Claude Code fixes are off by default: pin them

A changelog entry records how a tool behaved on one date, not how it behaves now. This post first ran on 5 May 2026 as a roundup of seven Claude Code changes from releases 2.1.121 through 2.1.128. Re-verified against the current documentation on 29 August 2026, two of those seven no longer describe how Claude Code behaves, and both were re-defaulted rather than removed. One of them quietly drops your unpushed commits again. Here is what moved, what still holds, and how we pin the behaviour we depend on.

Why a changelog roundup stops being true

Claude Code ships at a pace that makes any snapshot perishable. The npm registry lists 107 releases of @anthropic-ai/claude-code published between 5 May and 28 August 2026, ending at 2.1.251. The window this post originally covered was itself six releases across eight days.

Volume is not the problem. Almost all of those entries are additions, and an addition you have not read yet costs you nothing. The entries that turn a correct post into a wrong one are the reversals: a behaviour that shipped, then moved behind a flag, or went back to its old default because the new one had a cost nobody saw at review time. Those are rare enough to feel safe to ignore and consequential enough that ignoring them hurts.

A “Fixed” line is scoped to the release it shipped in. It says nothing about the release you are running today.

The reversals are easy to find once you know the shape of the sentence. In the Claude Code changelog they read as “was automatic in”, “is now opt-in via”, “matching pre-2.1.124 behavior”, or a bolded note that a new default “changes” something “back to” the old one. Both of the items below announce themselves that way.

The worktree fix that shipped, then went back to the old default

The original item was a genuine data-loss bug. EnterWorktree created new branches from origin/<default-branch> rather than your local HEAD, so any commit you had not pushed was simply absent from the new worktree. No error, no warning. Release 2.1.128 fixed it and the changelog said so plainly.

Three days later, 2.1.133 added a worktree.baseRef setting with two values, and its own changelog note is the correction: the default fresh changes EnterWorktree’s base back to origin/<default>. The fix became an option, and the option defaults to the behaviour the fix removed.

The current settings reference confirms it: worktree.baseRef has a default of "fresh", which branches from origin/<default-branch>. The alternative, "head", is described in the worktrees documentation as the value that will “branch from your current local HEAD, so the worktree carries your unpushed commits and feature-branch state”.

This bites harder than a single tool call suggests, because the same setting governs isolation for subagents. The worktrees documentation states that “Subagent worktrees use the same base branch as --worktree, so they branch from your repository’s default branch unless worktree.baseRef is set to "head"”. If you park in-progress work in local commits and then dispatch a subagent, that subagent starts from the remote’s default branch and cannot see the work you asked it to build on.

One line of committed configuration removes the whole class of problem:

{
  "worktree": {
    "baseRef": "head"
  }
}

To be fair to the design, fresh is a defensible default. A worktree that matches the remote is what most sessions want, and it is the safer starting point for an agent working unattended. The defect is not the default. It is trusting a four-month-old changelog line about it.

The gateway model list that became opt-in the same day

The second reversal is faster and more embarrassing. Release 2.1.126 made the /model picker list the models returned by an internal gateway’s /v1/models endpoint whenever ANTHROPIC_BASE_URL pointed at one, which mattered to any team routing Claude Code through a gateway for cost control or compliance. Release 2.1.129, published on 5 May 2026, made that discovery opt-in behind an environment variable. That is the same day this post first ran.

The reason is a good one, and Anthropic’s LLM gateway protocol documentation states it in one sentence: “Discovery is off by default so that gateways backed by a shared API key don’t surface every model the key can access to every user.” A team-wide default that leaks a shared key’s full model list to every developer is worth turning off, whatever it costs the people who liked the feature.

Turning it back on belongs in committed settings rather than in each developer’s shell profile, so the whole team gets it:

{
  "env": {
    "CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY": "1"
  }
}

Read the conditions before you rely on it. The same page notes that discovery never runs when a CLAUDE_CODE_USE_* provider variable is set, when ANTHROPIC_BASE_URL is unset or points at Anthropic’s own API, or when nonessential traffic is disabled by policy.

What still holds, and the mechanism the original post got wrong

Five of the original seven still describe current behaviour, and are still worth knowing:

• claude project purge [path] deletes a project’s local Claude Code state (transcripts, task lists, debug logs, file-edit history, prompt history lines, and the project’s entry in ~/.claude.json). It is in the current CLI reference with --dry-run, -y, -i and --all.
• Pasting the OAuth code straight into the terminal still fixes login in remote environments. The authentication documentation says this “happens when the browser can’t reach Claude Code’s local callback server, which is common in WSL2, SSH sessions, and containers”.
• Pasting a pull request URL into the /resume search box still finds the session that created it, across GitHub, GitHub Enterprise, GitLab and Bitbucket.
• A read-only shell command that exits non-zero, which is what grep does when it matches nothing, no longer cancels its sibling parallel tool calls.
• PostToolUse hooks can still replace the output of any tool, not only MCP tools.

That last one survived as a capability but not as described. The original post said the hook script “writes the replacement to stdout”, and a script that does exactly that will appear to do nothing. A PostToolUse hook returns a JSON object, and the replacement lives in updatedToolOutput, under hookSpecificOutput. The hooks reference is explicit about the constraint that makes a loose implementation fail silently: “The replacement value must match the tool’s output shape.” For built-in tools, a value that does not match the schema is ignored and the original output is used. Bash, for instance, returns an object rather than a string:

{
  "hookSpecificOutput": {
    "hookEventName": "PostToolUse",
    "updatedToolOutput": {
      "stdout": "[redacted]",
      "stderr": "",
      "interrupted": false,
      "isImage": false
    }
  }
}

Two further constraints decide whether this is the right tool for your job. The tool has already run by the time a PostToolUse hook fires, and telemetry captures the original output before the hook touches it. So output replacement is a context-hygiene control, useful for keeping secrets out of the model’s context, and it is not a prevention guardrail. To stop a call from happening, hook PreToolUse instead.

How we configure Claude Code for a moving target

None of this argues for updating less often. It argues for writing down the behaviours you actually depend on, in four cheap steps.

Commit the settings, do not remember them. A behaviour you rely on belongs in a checked-in .claude/settings.json, because a committed setting is the only version of “we branch from local HEAD” that survives a default change, a new laptop, or a teammate joining. This is the same reasoning we apply to the plugin stack we keep installed: configuration that lives only in someone’s head is not configuration.

Follow the stable channel on anything that matters. Setting autoUpdatesChannel to "stable" gives you, in the settings reference’s words, “a version that is typically about one week old and skips releases with major regressions”. That is about a week of other people finding the regressions for you, which is a good trade on a machine that runs unattended work.

{
  "autoUpdatesChannel": "stable"
}

Pair it with minimumVersion set to whatever you are running today, so switching channels never downgrades you below a version you already depend on.

Read the changelog for reversals, not only additions. Additions are opt-in by nature. Reversals change what you already have, and they hide in the middle of long release notes:

grep -iE 'opt-in|was automatic|back to|regression in' \
  CHANGELOG.md

Re-verify before you repeat a claim. Every fact in this rewrite came from the vendor’s current documentation and the registry’s own publish timestamps, not from the version of this post that already existed. That is the general habit: your agent’s summary is not a source, and neither is your own post from four months ago.

Conclusion

Two of the seven changes this post originally celebrated are no longer true, and neither was withdrawn. One became a setting whose default returned to the old behaviour, and one moved behind an environment variable on the day of publication. Both are recoverable in a few lines of committed configuration, and neither is discoverable by rereading the release notes you read the first time. Treat your agent harness the way you treat any other fast-moving dependency: pin the behaviour you depend on, follow a channel that lags on purpose, and re-check the claims you are still standing on.

Sources

• Claude Code changelog, the primary record for every release referenced here
• Claude Code settings reference for worktree.baseRef and autoUpdatesChannel defaults
• Claude Code worktrees documentation on base branches and subagent worktrees
• Claude Code hooks reference on PostToolUse output replacement
• Claude Code LLM gateway protocol on gateway model discovery
• npm registry entry for @anthropic-ai/claude-code for release counts and publish dates

Last updated: August 29, 2026