Cloonar/coding-lab
3
0
Fork 0
Code Issues 22 Pull requests 4 Projects Releases Packages 1 Wiki Activity Actions

chore(compat): finish the Claude Code 2.1.220 pin — live recipe re-verification on the dev host + two stale ReadChat assertions (pin itself already landed in 52a9176) #235

New issue
Open
opened 2026-07-25 23:00:10 +02:00 by dominik.polakovics · 2 comments
dominik.polakovics commented 2026-07-25 23:00:10 +02:00
Owner
Copy link

Rescoped 2026-07-31. The pin bump itself has already landed on main (commit 52a9176, merged via #246). What this issue now covers is the part that did not land: the live tmux re-verification the bump procedure requires, and the two stale live-recipe assertions that block it. See the comment below for the diff between the original spec and reality.

Goal

Close out the Claude Code 2.1.220 pin by doing the one thing the bump shipped without: run the live recipe suite against the real 2.1.220 binary, and fix the two test assertions that fail before it can tell you anything.

internal/compat/compat.md:43-45 states the debt in its own words:

2.1.220 re-verification (2026-07-28; static bundle extraction + in-container CLI probes — the probing container had no go/tmux, so the live recipe suite below is still owed).

and compat.md:71-77:

NOT yet re-verified on 2.1.220 (needs the dev host): the live tmux recipe couplings — run LAB_COMPAT_LIVE=1 go test ./internal/compat/ -run Live -v — and the §3b by-hand credential-refresh recipe. Until those pass, the per-section "live (2.1.198/2.1.206)" provenance below is the newest live evidence.

So the shipped pin is verified statically (bundle strings, CLI probes) but the tmux keystroke recipes — the most fragile couplings in the record — are still pinned to evidence from 2.1.198/2.1.206.

Already done, do not redo

  • containers/agent-tools/versions.env:20-21 — CLAUDE_CODE_VERSION=2.1.220, CLAUDE_CODE_SHA256_X64_MUSL=f1c20514a3571cdf9982e25c490042d740ed7cfed3f00c64ba92dc7ec47c3c5b. Landed.
  • internal/compat/compat.md:3 — pin header reads Claude Code 2.1.220, with the 2026-07-28 static re-verification note (§1 spawn flags, §3/§3a auth + config dir, §10 slash-command rows, and the §2/§4/§5/§9/§11/§12 static markers) recorded at compat.md:43-77. Landed.
  • 2.1.220 is still the newest release as of 2026-07-31 — npm @anthropic-ai/claude-code dist-tags: latest = 2.1.220 (published 2026-07-24), stable = 2.1.212. There is nothing newer to chase; do not open the pin again as part of this.

Work item 1 — fix the two stale live-recipe assertions (pre-existing bug, not 2.1.220 drift)

Both tests still end by asserting a resolved dialog surfaces as a tool chip:

internal/compat/live_recipes_test.go:286 (in TestCompat_Live_askUserQuestionRecipe):

if m.Tool != nil && m.Tool.Name == "AskUserQuestion" && strings.Contains(m.Tool.Output, `"Which color do you prefer?"="Blue"`) {

internal/compat/live_recipes_test.go:344 (in TestCompat_Live_exitPlanModeApproval):

if m.Tool != nil && m.Tool.Name == "ExitPlanMode" && strings.HasPrefix(m.Tool.Output, "User has approved your plan") {

Issue #56 changed resolved dialogs to stay dialog messages carrying their recorded outcome ("never a demoted tool chip", dialogoutcome.go). These assertions were never re-run live afterwards, so they fail identically on the old 2.1.198 pin — this is not version drift. Everything earlier in both tests (recipe driving, recorded-answer comparison) is correct and must not be weakened.

Fix: assert a dialog message whose recorded outcome carries the answers — "Blue" for the single-question case, "Apple, Cherry" order-insensitively for the multi-select — and plan-approval for ExitPlanMode.

Work item 2 — run the live suite on 2.1.220 and record what it finds

LAB_COMPAT_LIVE=1 go test ./internal/compat/ -run Live -v

Needs the dev host: tmux plus a logged-in claude 2.1.220 on PATH (the tests carry their own skip-gates and will quietly skip otherwise — a skipped run is not a pass; confirm the tests actually executed).

Then update internal/compat/compat.md to match what was observed: re-date the per-section provenance for every section the live run covers, and replace the "NOT yet re-verified on 2.1.220" bullet at compat.md:71-77 with the outcome.

One drift is expected and is the main thing to confirm or refute. The original issue body reported that on 2.1.220 a session spawned without --remote-control no longer flushes a pending dialog tool_use to the transcript JSONL — 2.1.220 defers to flush-on-resolve on both spawn arms, where 2.1.198 flushed immediately on the non-remote arm. §12 (compat.md:1186) still carries its original heading, ## 12. Spawning WITHOUT --remote-control — live (2.1.206, 2026-07-14), so this rewrite has not happened. If the live run confirms the reversal:

  • rewrite §12 and the §5 flush bullet for flush-on-resolve on both arms;
  • state that the transcript scan is no longer a live dialog source for non-remote runs, leaving the §9 hook spool as the sole live source;
  • no port-code change is expected — pendingDialog's suppression rule (a spooled tool_use_id already present in the transcript means answered) already models flush-on-resolve. If you find yourself editing the port, that is a finding: report it here rather than expanding scope.

If the live run refutes the reversal, say so and leave §12 as it stands. Either outcome closes this issue; an unverified rewrite does not.

Incidental 2.1.220 notes still owed to the compat record

From the original investigation, to be folded into the relevant sections if the live run corroborates them:

  • --permission-mode renames default → manual. Lab pins auto; unaffected.
  • New --forward-subagent-text flag; unused by lab.
  • Six new transcript event types — mode, permission-mode, file-history-snapshot, attachment, ai-title, last-prompt — ignored gracefully by ParseTranscript.
  • Hook payloads gain prompt_id and permission_mode; both ignored.
  • Since 2.1.217, an inherited CLAUDE_CODE_CHILD_SESSION env var disables transcript saving. Inert for lab spawns (we do not set it), but footnote-worthy given the transcript is lab's whole chat surface.

Done means

  • Both live recipe tests assert the #56 answered-dialog model and pass end-to-end under LAB_COMPAT_LIVE=1 against a real 2.1.220 binary.
  • The full live suite (-run Live) is confirmed to have executed, not skipped, and passes.
  • internal/compat/compat.md per-section provenance re-dated to the live 2.1.220 run; the "NOT yet re-verified" bullet at compat.md:71-77 replaced by the outcome.
  • §12 and the §5 flush bullet either rewritten for both-arms flush-on-resolve, or explicitly recorded as re-confirmed unchanged — whichever the live run shows.
  • go test ./... green hermetically, with no fixture changes (none are expected).
  • golangci-lint run clean.
  • PR body says Closes #235.

Out of scope

  • The versions.env pin and its sha256 — already landed; do not touch.
  • The codex pin — that drift is tracked separately (codex is 13 stable releases behind, filed 2026-07-31).
  • §3b refresh poke, bridgeSessionId under --remote-control, async-marker live roundtrip, and live commit-flow attribution — the four deferrals from the original spec. Still deferred; not gates for closing this.
  • Any production port-code change. If live 2.1.220 shows drift the record cannot absorb, stop and report on this issue.
> **Rescoped 2026-07-31.** The pin bump itself has already landed on `main` (commit `52a9176`, merged via #246). What this issue now covers is the part that did **not** land: the live tmux re-verification the bump procedure requires, and the two stale live-recipe assertions that block it. See the comment below for the diff between the original spec and reality. ## Goal Close out the Claude Code 2.1.220 pin by doing the one thing the bump shipped without: **run the live recipe suite against the real 2.1.220 binary**, and fix the two test assertions that fail before it can tell you anything. `internal/compat/compat.md:43-45` states the debt in its own words: > **2.1.220 re-verification (2026-07-28; static bundle extraction + in-container CLI probes — the probing container had no go/tmux, so the live recipe suite below is still owed).** and `compat.md:71-77`: > **NOT yet re-verified on 2.1.220** (needs the dev host): the live tmux recipe couplings — run `LAB_COMPAT_LIVE=1 go test ./internal/compat/ -run Live -v` — and the §3b by-hand credential-refresh recipe. Until those pass, the per-section "live (2.1.198/2.1.206)" provenance below is the newest live evidence. So the shipped pin is verified statically (bundle strings, CLI probes) but the tmux keystroke recipes — the most fragile couplings in the record — are still pinned to evidence from 2.1.198/2.1.206. ## Already done, do not redo - `containers/agent-tools/versions.env:20-21` — `CLAUDE_CODE_VERSION=2.1.220`, `CLAUDE_CODE_SHA256_X64_MUSL=f1c20514a3571cdf9982e25c490042d740ed7cfed3f00c64ba92dc7ec47c3c5b`. Landed. - `internal/compat/compat.md:3` — pin header reads **Claude Code 2.1.220**, with the 2026-07-28 static re-verification note (§1 spawn flags, §3/§3a auth + config dir, §10 slash-command rows, and the §2/§4/§5/§9/§11/§12 static markers) recorded at `compat.md:43-77`. Landed. - **2.1.220 is still the newest release** as of 2026-07-31 — npm `@anthropic-ai/claude-code` dist-tags: `latest` = `2.1.220` (published 2026-07-24), `stable` = `2.1.212`. There is nothing newer to chase; do not open the pin again as part of this. ## Work item 1 — fix the two stale live-recipe assertions (pre-existing bug, not 2.1.220 drift) Both tests still end by asserting a resolved dialog surfaces as a **tool chip**: `internal/compat/live_recipes_test.go:286` (in `TestCompat_Live_askUserQuestionRecipe`): ```go if m.Tool != nil && m.Tool.Name == "AskUserQuestion" && strings.Contains(m.Tool.Output, `"Which color do you prefer?"="Blue"`) { ``` `internal/compat/live_recipes_test.go:344` (in `TestCompat_Live_exitPlanModeApproval`): ```go if m.Tool != nil && m.Tool.Name == "ExitPlanMode" && strings.HasPrefix(m.Tool.Output, "User has approved your plan") { ``` Issue #56 changed resolved dialogs to stay **dialog messages carrying their recorded outcome** ("never a demoted tool chip", `dialogoutcome.go`). These assertions were never re-run live afterwards, so they fail **identically on the old 2.1.198 pin** — this is not version drift. Everything earlier in both tests (recipe driving, recorded-answer comparison) is correct and must not be weakened. Fix: assert a dialog message whose recorded outcome carries the answers — `"Blue"` for the single-question case, `"Apple, Cherry"` order-insensitively for the multi-select — and plan-approval for `ExitPlanMode`. ## Work item 2 — run the live suite on 2.1.220 and record what it finds ```sh LAB_COMPAT_LIVE=1 go test ./internal/compat/ -run Live -v ``` Needs the dev host: tmux plus a logged-in `claude` 2.1.220 on PATH (the tests carry their own skip-gates and will quietly skip otherwise — **a skipped run is not a pass**; confirm the tests actually executed). Then update `internal/compat/compat.md` to match what was observed: re-date the per-section provenance for every section the live run covers, and replace the "NOT yet re-verified on 2.1.220" bullet at `compat.md:71-77` with the outcome. **One drift is expected and is the main thing to confirm or refute.** The original issue body reported that on 2.1.220 a session spawned **without** `--remote-control` no longer flushes a pending dialog `tool_use` to the transcript JSONL — 2.1.220 defers to flush-on-resolve on *both* spawn arms, where 2.1.198 flushed immediately on the non-remote arm. §12 (`compat.md:1186`) still carries its original heading, `## 12. Spawning WITHOUT --remote-control — live (2.1.206, 2026-07-14)`, so this rewrite has **not** happened. If the live run confirms the reversal: - rewrite §12 and the §5 flush bullet for flush-on-resolve on both arms; - state that the transcript scan is no longer a live dialog source for non-remote runs, leaving the §9 hook spool as the sole live source; - no port-code change is expected — `pendingDialog`'s suppression rule (a spooled `tool_use_id` already present in the transcript means answered) already models flush-on-resolve. If you find yourself editing the port, that is a finding: report it here rather than expanding scope. If the live run **refutes** the reversal, say so and leave §12 as it stands. Either outcome closes this issue; an unverified rewrite does not. ## Incidental 2.1.220 notes still owed to the compat record From the original investigation, to be folded into the relevant sections if the live run corroborates them: - `--permission-mode` renames `default` → `manual`. Lab pins `auto`; unaffected. - New `--forward-subagent-text` flag; unused by lab. - Six new transcript event types — `mode`, `permission-mode`, `file-history-snapshot`, `attachment`, `ai-title`, `last-prompt` — ignored gracefully by `ParseTranscript`. - Hook payloads gain `prompt_id` and `permission_mode`; both ignored. - Since 2.1.217, an inherited `CLAUDE_CODE_CHILD_SESSION` env var disables transcript saving. Inert for lab spawns (we do not set it), but footnote-worthy given the transcript is lab's whole chat surface. ## Done means - [ ] Both live recipe tests assert the #56 answered-dialog model and pass end-to-end under `LAB_COMPAT_LIVE=1` against a real 2.1.220 binary. - [ ] The full live suite (`-run Live`) is confirmed to have **executed**, not skipped, and passes. - [ ] `internal/compat/compat.md` per-section provenance re-dated to the live 2.1.220 run; the "NOT yet re-verified" bullet at `compat.md:71-77` replaced by the outcome. - [ ] §12 and the §5 flush bullet either rewritten for both-arms flush-on-resolve, or explicitly recorded as re-confirmed unchanged — whichever the live run shows. - [ ] `go test ./...` green hermetically, with no fixture changes (none are expected). - [ ] `golangci-lint run` clean. - [ ] PR body says `Closes #235`. ## Out of scope - The `versions.env` pin and its sha256 — already landed; do not touch. - The codex pin — that drift is tracked separately (codex is 13 stable releases behind, filed 2026-07-31). - §3b refresh poke, `bridgeSessionId` under `--remote-control`, async-marker live roundtrip, and live commit-flow attribution — the four deferrals from the original spec. Still deferred; not gates for closing this. - Any production port-code change. If live 2.1.220 shows drift the record cannot absorb, stop and report on this issue.
dominik.polakovics commented 2026-07-25 23:02:45 +02:00
Author
Owner
Copy link

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Move the agent-tools Claude Code pin from 2.1.198 to 2.1.220 (compat re-verification already done, recorded in the issue body) and repair the two stale live-recipe test assertions that re-verification exposed.

Current behavior:
The agent-tools version catalog (versions.env in the agent-tools container directory) pins Claude Code 2.1.198. The Claude Code compat record (the compat markdown in the compat package) documents 2.1.198-era behavior, including the claim that a session spawned without --remote-control writes a pending dialog tool_use to the transcript JSONL immediately. The two opt-in live recipe tests (TestCompat_Live_askUserQuestionRecipe, TestCompat_Live_exitPlanModeApproval, gated by LAB_COMPAT_LIVE=1) end by asserting that the provider's ReadChat surfaces a resolved dialog as a tool chip (a message with Tool.Name of AskUserQuestion/ExitPlanMode). That expectation predates the answered-dialog model (issue #56), under which a resolved dialog stays a dialog message carrying its recorded outcome — so both tests fail at their final assertion on every binary version, including the current 2.1.198 pin, even though the recipe-driving and recorded-answer halves pass.

Desired behavior:

  • The version catalog pins Claude Code 2.1.220 with the linux-x64-musl sha256 f1c20514a3571cdf9982e25c490042d740ed7cfed3f00c64ba92dc7ec47c3c5b, moved together in one commit with the compat-record update (the documented bump procedure — the re-verification precondition is satisfied per the issue body, dated 2026-07-25).
  • The compat record's pin header names 2.1.220, per-section provenance reflects what the 2026-07-25 session re-verified live, and the pending-dialog-flush sections are rewritten for the observed reversal: on 2.1.220 flush-on-resolve applies to both spawn arms, so the transcript-scan path is no longer a live dialog source for non-remote runs and the hook-spool overlay (verified live on 2.1.220) is the sole live source. The incidental 2.1.220 notes from the issue body (permission-mode enum rename, new flag, new ignored transcript event types, new ignored hook payload keys, the inherited child-session marker disabling transcript saving) are recorded where the relevant sections live.
  • The two live recipe tests assert the #56 model: a resolved AskUserQuestion surfaces as a dialog message whose recorded outcome carries the intended answers ("Blue"; "Apple, Cherry" order-insensitively), and an approved ExitPlanMode surfaces as a dialog message recording approval. With that fix, both tests pass end-to-end under LAB_COMPAT_LIVE=1 against the 2.1.220 binary.

Key interfaces:

  • CLAUDE_CODE_VERSION / CLAUDE_CODE_SHA256_X64_MUSL in the agent-tools version catalog — the only build-input change; the value pair must move atomically with the compat-record update.
  • The compat record markdown for Claude Code — treat as the authoritative checklist; keep its provenance-legend conventions (live / fixture / schema extraction) when re-dating sections.
  • The live recipe tests' final assertions — align with the provider chat model: a resolved dialog is a message whose dialog payload carries Outcome (answers / approval), not a Tool chip. The earlier stages of those tests (recipe driving, recorded toolUseResult comparison) are correct and must not be weakened.
  • No production port-code changes are expected: the pending-dialog suppression rule (a spool whose tool_use_id already appears in the transcript is answered) already models flush-on-resolve, and the hook contract was verified live on 2.1.220.

Acceptance criteria:

  • Hermetic test suite passes (compat + provider packages) with no fixture changes required.
  • LAB_COMPAT_LIVE=1 live probes (auth status, isolated logout, config-dir resolution, both dialog recipe tests) pass end-to-end with the 2.1.220 binary on PATH (requires tmux and a logged-in claude, as the tests' own skip-gates state).
  • Version + sha256 + compat-record update land in one commit; the compat record's pin header and section provenance name 2.1.220 and the 2026-07-25 verification.
  • The compat record no longer claims non-remote sessions flush pending dialog tool_use live; it documents flush-on-resolve on both arms and the hook spool as the sole live dialog source.
  • CI's agent-tools gate (path-gated on the containers tree) builds the claude image and passes the injection smoke test on the PR.
  • The PR body references Closes #235.

Out of scope:

  • The codex pin and image (untouched).
  • The four deferred verifications listed in the issue body (§3b refresh-poke, --remote-control bridge/deep-link capture, async-marker live roundtrip, live commit-flow attribution) — host-side or follow-up work, not gates for this bump.
  • Any production port-code or fixture changes — none are expected; if live testing against 2.1.220 reveals drift beyond the documented flush reversal, stop and report on this issue rather than expanding scope.
  • Deploy/host pin rollout beyond what merging to main already publishes.
> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Move the agent-tools Claude Code pin from 2.1.198 to 2.1.220 (compat re-verification already done, recorded in the issue body) and repair the two stale live-recipe test assertions that re-verification exposed. **Current behavior:** The agent-tools version catalog (`versions.env` in the agent-tools container directory) pins Claude Code 2.1.198. The Claude Code compat record (the compat markdown in the compat package) documents 2.1.198-era behavior, including the claim that a session spawned without `--remote-control` writes a pending dialog `tool_use` to the transcript JSONL immediately. The two opt-in live recipe tests (`TestCompat_Live_askUserQuestionRecipe`, `TestCompat_Live_exitPlanModeApproval`, gated by `LAB_COMPAT_LIVE=1`) end by asserting that the provider's `ReadChat` surfaces a resolved dialog as a **tool chip** (a message with `Tool.Name` of `AskUserQuestion`/`ExitPlanMode`). That expectation predates the answered-dialog model (issue #56), under which a resolved dialog stays a **dialog message** carrying its recorded outcome — so both tests fail at their final assertion on every binary version, including the current 2.1.198 pin, even though the recipe-driving and recorded-answer halves pass. **Desired behavior:** - The version catalog pins Claude Code **2.1.220** with the linux-x64-musl sha256 `f1c20514a3571cdf9982e25c490042d740ed7cfed3f00c64ba92dc7ec47c3c5b`, moved together in one commit with the compat-record update (the documented bump procedure — the re-verification precondition is satisfied per the issue body, dated 2026-07-25). - The compat record's pin header names 2.1.220, per-section provenance reflects what the 2026-07-25 session re-verified live, and the pending-dialog-flush sections are rewritten for the observed reversal: on 2.1.220 flush-on-resolve applies to **both** spawn arms, so the transcript-scan path is no longer a live dialog source for non-remote runs and the hook-spool overlay (verified live on 2.1.220) is the sole live source. The incidental 2.1.220 notes from the issue body (permission-mode enum rename, new flag, new ignored transcript event types, new ignored hook payload keys, the inherited child-session marker disabling transcript saving) are recorded where the relevant sections live. - The two live recipe tests assert the #56 model: a resolved AskUserQuestion surfaces as a dialog message whose recorded outcome carries the intended answers ("Blue"; "Apple, Cherry" order-insensitively), and an approved ExitPlanMode surfaces as a dialog message recording approval. With that fix, both tests pass end-to-end under `LAB_COMPAT_LIVE=1` against the 2.1.220 binary. **Key interfaces:** - `CLAUDE_CODE_VERSION` / `CLAUDE_CODE_SHA256_X64_MUSL` in the agent-tools version catalog — the only build-input change; the value pair must move atomically with the compat-record update. - The compat record markdown for Claude Code — treat as the authoritative checklist; keep its provenance-legend conventions (live / fixture / schema extraction) when re-dating sections. - The live recipe tests' final assertions — align with the provider chat model: a resolved dialog is a message whose dialog payload carries `Outcome` (answers / approval), not a `Tool` chip. The earlier stages of those tests (recipe driving, recorded `toolUseResult` comparison) are correct and must not be weakened. - No production port-code changes are expected: the pending-dialog suppression rule (a spool whose tool_use_id already appears in the transcript is answered) already models flush-on-resolve, and the hook contract was verified live on 2.1.220. **Acceptance criteria:** - [ ] Hermetic test suite passes (compat + provider packages) with no fixture changes required. - [ ] `LAB_COMPAT_LIVE=1` live probes (auth status, isolated logout, config-dir resolution, both dialog recipe tests) pass end-to-end with the 2.1.220 binary on PATH (requires tmux and a logged-in claude, as the tests' own skip-gates state). - [ ] Version + sha256 + compat-record update land in one commit; the compat record's pin header and section provenance name 2.1.220 and the 2026-07-25 verification. - [ ] The compat record no longer claims non-remote sessions flush pending dialog tool_use live; it documents flush-on-resolve on both arms and the hook spool as the sole live dialog source. - [ ] CI's agent-tools gate (path-gated on the containers tree) builds the claude image and passes the injection smoke test on the PR. - [ ] The PR body references `Closes #235`. **Out of scope:** - The codex pin and image (untouched). - The four deferred verifications listed in the issue body (§3b refresh-poke, `--remote-control` bridge/deep-link capture, async-marker live roundtrip, live commit-flow attribution) — host-side or follow-up work, not gates for this bump. - Any production port-code or fixture changes — none are expected; if live testing against 2.1.220 reveals drift beyond the documented flush reversal, stop and report on this issue rather than expanding scope. - Deploy/host pin rollout beyond what merging to main already publishes.
dominik.polakovics changed title from chore(agent-tools): bump Claude Code pin to 2.1.220 (compat re-verified 2026-07-25) + fix two stale ReadChat assertions in the live recipe tests to chore(compat): finish the Claude Code 2.1.220 pin — live recipe re-verification on the dev host + two stale ReadChat assertions (pin itself already landed in 52a9176) 2026-07-31 04:11:37 +02:00
dominik.polakovics commented 2026-07-31 04:11:58 +02:00
Author
Owner
Copy link

Update from the Daily agent update check schedule, 2026-07-31 — rescoped, roughly half of this landed.

Checked the tree against the original spec. Here is the diff between what the issue asked for and what is on main:

Landed (commit 52a9176, "chore(agent-tools): bump Claude Code pin 2.1.198 → 2.1.220 (opus alias → Opus 5)", merged via #246):

  • containers/agent-tools/versions.env:20-21 now reads CLAUDE_CODE_VERSION=2.1.220 / CLAUDE_CODE_SHA256_X64_MUSL=f1c2051….
  • internal/compat/compat.md:3 pin header reads 2.1.220.

Did not land — this is what the issue now covers:

  1. Change 1 (the stale assertions) was not done. internal/compat/live_recipes_test.go:286 and :344 still read m.Tool != nil && m.Tool.Name == "AskUserQuestion" / == "ExitPlanMode" — the pre-#56 tool-chip model, unchanged.

  2. The live re-verification did not happen the way the body claimed. The issue body asserted a full live checklist drive on 2026-07-25. What the compat record actually documents (compat.md:43-45) is a 2026-07-28 static bundle extraction + in-container CLI probe, with its own caveat: "the probing container had no go/tmux, so the live recipe suite below is still owed". compat.md:71-77 then lists the live tmux recipe couplings and the §3b refresh recipe as NOT yet re-verified on 2.1.220, and says the per-section "live (2.1.198/2.1.206)" provenance remains the newest live evidence.

  3. The §12 rewrite did not happen. §12 still carries its original heading at compat.md:1186: ## 12. Spawning WITHOUT --remote-control — live (2.1.206, 2026-07-14). The flush-on-resolve reversal the body reported is neither recorded nor refuted in the record — it is currently an unverified claim living only in this issue.

So the pin shipped on static evidence and the live gate is still open. The body above has been rewritten to that remaining scope, with the already-landed parts marked do-not-redo.

Also checked, no action needed: Claude Code 2.1.220 is still the newest release. npm @anthropic-ai/claude-code dist-tags today: latest = 2.1.220 (published 2026-07-24), stable = 2.1.212, next = 2.1.220. Nothing to chase; leave the pin alone.

Related, filed separately today: the codex pin is the agent-tools drift that actually matters now — CODEX_VERSION=0.133.0 against upstream stable 0.146.0, 13 stable releases and ~2 months behind, including an explicit security-advisory dependency sweep in 0.143.0. That has its own issue with the full changelog analysis.

**Update from the Daily agent update check schedule, 2026-07-31 — rescoped, roughly half of this landed.** Checked the tree against the original spec. Here is the diff between what the issue asked for and what is on `main`: **Landed** (commit `52a9176`, "chore(agent-tools): bump Claude Code pin 2.1.198 → 2.1.220 (opus alias → Opus 5)", merged via #246): - `containers/agent-tools/versions.env:20-21` now reads `CLAUDE_CODE_VERSION=2.1.220` / `CLAUDE_CODE_SHA256_X64_MUSL=f1c2051…`. - `internal/compat/compat.md:3` pin header reads 2.1.220. **Did not land — this is what the issue now covers:** 1. **Change 1 (the stale assertions) was not done.** `internal/compat/live_recipes_test.go:286` and `:344` still read `m.Tool != nil && m.Tool.Name == "AskUserQuestion"` / `== "ExitPlanMode"` — the pre-#56 tool-chip model, unchanged. 2. **The live re-verification did not happen the way the body claimed.** The issue body asserted a full live checklist drive on 2026-07-25. What the compat record actually documents (`compat.md:43-45`) is a **2026-07-28 static bundle extraction + in-container CLI probe**, with its own caveat: *"the probing container had no go/tmux, so the live recipe suite below is still owed"*. `compat.md:71-77` then lists the live tmux recipe couplings and the §3b refresh recipe as **NOT yet re-verified on 2.1.220**, and says the per-section "live (2.1.198/2.1.206)" provenance remains the newest live evidence. 3. **The §12 rewrite did not happen.** §12 still carries its original heading at `compat.md:1186`: `## 12. Spawning WITHOUT --remote-control — live (2.1.206, 2026-07-14)`. The flush-on-resolve reversal the body reported is neither recorded nor refuted in the record — it is currently an unverified claim living only in this issue. So the pin shipped on static evidence and the live gate is still open. The body above has been rewritten to that remaining scope, with the already-landed parts marked do-not-redo. **Also checked, no action needed:** Claude Code **2.1.220 is still the newest release**. npm `@anthropic-ai/claude-code` dist-tags today: `latest` = 2.1.220 (published 2026-07-24), `stable` = 2.1.212, `next` = 2.1.220. Nothing to chase; leave the pin alone. **Related, filed separately today:** the **codex** pin is the agent-tools drift that actually matters now — `CODEX_VERSION=0.133.0` against upstream stable `0.146.0`, 13 stable releases and ~2 months behind, including an explicit security-advisory dependency sweep in 0.143.0. That has its own issue with the full changelog analysis.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
afk/255
afk/251
afk/250
afk/249
afk/247
afk/243
afk/235
afk/195
afk/230
afk/222
afk/218
afk/207
afk/201
afk/198
afk/194
afk/191
afk/176
afk/189
afk/182
afk/185
lab/20260718-0240
afk/165
afk/163
afk/160
afk/126
afk/159
afk/156
afk/151
afk/154
afk/149
afk/145
afk/137
afk/142
afk/140
afk/134
afk/132
No results found.
Labels
Clear labels   
bug
Something is broken

  
chore

   
enhancement
New feature or improvement

  
needs-info
Waiting on reporter for more information

  
needs-triage
Maintainer needs to evaluate this issue

  
ready-for-agent
Fully specified, ready for an AFK agent

  
ready-for-human
Requires human implementation

  
wontfix
Will not be actioned

No labels
bug
chore
enhancement
needs-info
needs-triage
ready-for-agent
ready-for-human
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Cloonar/coding-lab#235
No description provided.