Canary first, production second — the point of pinning is that the upgrade is a
decision, and the point of `canary-claude` is that the decision has evidence.
Taken for 2.1.225's fix to a transient 401 that replaced a long-lived
CLAUDE_CODE_OAUTH_TOKEN with a short-lived one and broke HEADLESS sessions until
restart. Our sessions are headless and our VMs are per-mission, so "until
restart" reads as a failed phase.
The 2.1.225 workspace-trust prompt does NOT apply: `--help` states the dialog is
skipped in non-interactive mode (`-p`, or stdout not a TTY) and we satisfy both.
Read from the CLI in a booted 2.1.226 VM rather than inferred from the changelog.
Verified on the production path after the rebuild: guest kernel 6.1.128,
delegation to a subagent, `--settings` stop gate installed, judge independent
(glm-4.7), single writer. 6/6.
`rootfs-canary-claude.ext4` is left on tank as the mechanism for the next
candidate, not as a leftover.
Omar Sobh
8b12245e79