chore: bump claude_version to 2.1.226

[tend-agent]

Weekly pin refresh: claude_version 2.1.220 → 2.1.226 (npm dist-tags.latest). A stale binary resolves --model opus/sonnet to a superseded alias target, so the pin is worth moving even on a run of quiet releases.

CHANGELOG skim across 2.1.221 → 2.1.226, restricted to the paths this action exercises (headless -p, the credential-injection proxy, plugin skills, OAuth-token auth):

• 2.1.225 — headless OAuth token. "Fixed a transient 401 replacing a long-lived CLAUDE_CODE_OAUTH_TOKEN with a stored login's short-lived token, breaking headless sessions until restart." This is exactly tend's auth shape; the failure mode was a session that dies partway and can't recover without a restart the action never does.
• 2.1.222 — HTTPS proxy. "Fixed the startup connectivity check hanging and then failing behind an HTTPS proxy; it now uses the same proxy-aware transport as API requests and times out with a clear message." Every tend session starts behind mitmdump, so this removes a hang class at the point where the proxy has just come up.
• 2.1.221 — sandbox proxy + non-interactive skills. "Fixed sandboxed large uploads failing with TLS errors through the sandbox proxy", and "Fixed plugin- and org-delivered skills named after terminal-only built-ins (e.g. /help, /feedback) being un-invocable in non-interactive sessions" — tend ships its skills as a plugin and invokes them from a non-interactive run.
• 2.1.223 — /review is now an alias of /code-review. No action needed, but the reason isn't which skill the review path calls — it's that code_review_notice in generator/src/tend/config.py puts a bare /code-review token into every generated Claude prompt, to trip the Skill tool's disable-model-invocation waiver. The scan reading that token lives in the binary, so a release touching /code-review handling is precisely the change class that could unhook it with nothing failing — the run would just lose its second pass. Verified against the 2.1.226 binary rather than the CHANGELOG: the scan still builds its regex from the command name ((?<!\S)/${name}(?=$|\s)), and the canonical name is still code-review — 2.1.223 added /review as an alias rather than renaming it. skills(running-tend): check the /code-review waiver scan when bumping claude_version #926 folds this check into the weekly bump rule so the next bump doesn't have to re-derive it.
• 2.1.226 is bug fixes and reliability only; 2.1.224 is feature work on surfaces this action doesn't touch (self-hosted runners, Remote Control, VS Code).

Nothing in the range changes -p result events, --model alias resolution, first-run onboarding, or Stop-hook behavior.

mitmproxy_version is already at latest (12.2.3), so uv_version stays put too — per running-tend, uv moves with mitmproxy rather than on a stream of its own.

The pin resolves on the channel the install actually uses, not just npm: 2.1.226/manifest.json exists in the release bucket and the downloaded linux-x64 binary's sha256 matches its manifest entry. Note that it now sits ahead of that bucket's own stable marker, which currently reads 2.1.220 — the version this PR replaces. That's the rule as written ("track latest"), not a defect here; #927 raises whether latest is the marker we want to keep tracking.

[tend-agent]

Bump itself is correct and safe to land — 2.1.226 resolves on the channel install-claude-binary.sh actually fetches from (not just npm), and the one binary-internal behaviour this repo depends on survives the range. Two notes, neither blocking.

The 2.1.223 /code-review entry is load-bearing, for a reason the body doesn't name. The body waves it off with "the review skill already routes through the tend-owned /tend-ci-runner:code-review rather than the built-in" — true, but that's not where the dependency lives. code_review_notice in generator/src/tend/config.py puts a bare /code-review token into every generated Claude prompt, precisely to trip the binary's disable-model-invocation waiver scan, and default_prompt's docstring pins that scan's regex as read out of the 2.1.220 binary. So a release that changes /code-review command handling is exactly the change class that could silently unhook it — no error, the run just loses its second pass. The conclusion ("no action needed") holds, but it needed checking against the new binary rather than against which skill the review path calls. I checked; it's intact (evidence below).

The pin now runs ahead of the installer's own stable channel. https://downloads.claude.ai/claude-code-releases/ publishes both markers, and right now stable is 2.1.220 — exactly the version this PR is replacing — while latest is 2.1.226, six patch releases ahead. That's not a defect here: running-tend says "track latest" and names npm view … dist-tags.latest, and this PR followed it. It's the policy that's worth a look, since the same gap will recur every week: tracking latest means every adopter's CI runs the release Anthropic hasn't promoted yet, and the promotion lag is roughly one weekly bump cycle. Worth deciding deliberately given this binary runs in every consumer's job.

Verification

Pin resolves on the install channel. shared/steps/install-claude-binary.sh passes the version to claude.ai/install.sh, which fetches $BASE/$version/$platform/claude — npm's dist-tags don't guarantee that path exists:

$ curl -fsS https://downloads.claude.ai/claude-code-releases/2.1.226/manifest.json | jq -r '.platforms["linux-x64"]'
{ "binary": "claude", "checksum": "4e9bec1177ce9690e8bd988b710ac24105e70da428dd094c5adcbbe786a55555", "size": 297831432 }

$ curl -fsSL .../2.1.226/linux-x64/claude -o claude-2.1.226 && sha256sum claude-2.1.226
4e9bec1177ce9690e8bd988b710ac24105e70da428dd094c5adcbbe786a55555  claude-2.1.226   # matches manifest

Channel markers, same base URL: stable → 2.1.220, latest → 2.1.226.

Waiver scan intact in 2.1.226. Grepping the downloaded binary, the scan is still the regex default_prompt's docstring pins, still built from the command name, still skipping meta messages, tool_result content, and <command-message>-wrapped messages (which is why the prompt is prose rather than a leading slash command):

function $8b(e,t){ if(t.agentId!==void 0)return!1;
  let r=new RegExp(`(?<!\\S)/${f2(e)}(?=$|\\s)`);
  for(let n=t.messages.length-1;n>=t.turnStartIndex;n--){ let o=t.messages[n];
    if(o.type!=="user"||o.isMeta)continue; let i=o.message.content;
    if(typeof i==="string"){if(i.includes(`<${ok}>`))continue}
    else if(i.some((s)=>s.type==="tool_result"))continue;
    if(r.test(wP(o)??""))return!0 } return!1 }

And the command name is unchanged, so the /code-review token still matches: CODE_REVIEW_WORKFLOW_NAME="code-review". The 2.1.223 change added /review as an alias rather than renaming the canonical form.

CHANGELOG quotes in the body all verify verbatim, including per-version attribution — 2.1.225 headless CLAUDE_CODE_OAUTH_TOKEN 401, 2.1.222 HTTPS-proxy connectivity check, 2.1.221 sandbox-proxy TLS uploads and non-interactive plugin skills named after terminal-only built-ins. Nothing in 2.1.221–2.1.226 touches -p result events, --model alias resolution, first-run onboarding, or Stop-hook behaviour.

mitmproxy_version/uv_version correctly left alone: mitmproxy latest is 12.2.3, which the action already pins.

[tend-agent]

Both notes land. Taking them in turn.

The /code-review dependency. Correct, and the body was reasoning from the wrong place — the routing of the review skill isn't what holds that token in the prompt, code_review_notice is. I re-verified independently rather than taking the review's word: the downloaded linux-x64 binary for 2.1.226 checksums to 4e9bec11…a55555, matching its manifest.json, and both halves of the contract are intact in it — the scan still builds (?<!\S)/${name}(?=$|\s) from the command name, and the canonical name is still code-review, so 2.1.223's /review is an alias rather than a rename. Body updated to carry that reasoning instead.

One correction to the review itself: the docstring pins the regex, but it doesn't record which binary version it was read out of, and neither does test_default_prompt_unlocks_code_review — the test asserts our prompt matches the regex we wrote down, so it stays green no matter what the binary does. That's the actual hole, and it's why the fix belongs in the bump rule rather than in a comment here: #926 adds the binary-side check to running-tend's weekly claude_version procedure, with the two greps verified against 2.1.226. Without it the next bump re-derives this from scratch, which is exactly what went wrong on this one.

latest vs stable. Confirmed — stable is 2.1.220, latest is 2.1.226, and 2.1.220 is the pin this PR replaces, so the promotion lag runs about one bump cycle and adopters are permanently a cycle ahead of the promoted release. Raised as #927 rather than resolved here, because it argues in both directions: 2.1.225's headless CLAUDE_CODE_OAUTH_TOKEN 401 fix and 2.1.222's HTTPS-proxy hang fix are both squarely tend's shapes, so waiting for stable has a real cost too. claude install accepts stable, latest, or an exact version, so all three are on the table; the pin stays an exact version either way, and only the marker we read each week is in question.

Neither changes the bump, which stays as-is.