Fix Entire Attach for Growing Sessions

I’ll trace how entire attach finds and updates a session when the agent starts above the repos, then build a small repro for the second commit and identify a fix.

I found a likely cause: once a session has a checkpoint, attach links that old checkpoint and returns before reading the transcript again. That would make the second commit show only the first part of the conversation. I’m verifying it with two commits and a transcript that grows between them.

The repro confirms it on both checkpoint backends: the second attach succeeds, reuses the first checkpoint ID, and checkpoint explain --transcript returns unchanged bytes without the second turn.

I’ve added an opt-in regression repro. The fix should capture the current transcript for the new commit while preserving the first commit’s snapshot; it also needs to keep repeated attaches idempotent when nothing has changed.

Confirmed: the second attach links the old checkpoint without reading the updated transcript. The early return is in attach.go:243.

I added a repro test that simulates a workspace-level Claude session:

1. Commit and attach the first conversation turn.
2. Extend the transcript, make another commit, and attach again.
3. Read the second checkpoint through the CLI.

Both storage backends reproduce it: same checkpoint ID, unchanged transcript, missing second turn. No plugin or real agent is needed.

Run it with:

Proposed fix: replace the unconditional LastCheckpointID shortcut with transcript-aware behavior. New conversation on a new commit should create a new checkpoint, preserve the first snapshot, and advance transcript/token accounting. An unchanged repeat attach should remain idempotent.

Production code is unchanged. The repro intentionally fails behind an opt-in tag; the normal integration suite passed (692 tests reported, 6 skipped).

Yes—the same ongoing conversation/session should produce multiple checkpoints as it progresses.

Commit 1 captures the conversation up to that point; commit 2 captures its updated state, including later messages. The session ID stays the same, but the checkpoint ID changes. My wording “new conversation” should have been “new messages in the same conversation.”

I’ll implement repeated attach for a growing session, preserving earlier snapshots and keeping unchanged repeats idempotent. I’ll use the repro to verify the fix.

I’m making the commit the attachment boundary: a new commit captures the latest transcript from the same session; attaching again to a commit that already contains that session remains a no-op. I’ll also scope the second checkpoint’s token usage to the new portion of an append-only transcript.

The original repro now passes on both backends: the second commit gets a new checkpoint with the later messages, and the first snapshot stays unchanged. The existing attach tests pass too. I’m checking repeat attaches, transcript rewrites, and token accounting before running the broader suite.

The focused checks pass, including token scoping, rewritten transcripts, and repeat attaches after local session state is removed. Lint is clean. The broader suites have reported failures outside attach; I’m checking those separately to determine whether they affect this fix.

All attach tests pass, and the three integration failures passed on a separate rerun. The unit suite passed 12,891 tests and had one failure in external-agent discovery. I’m rechecking that failure and rerunning integration without the competing full-suite load.

Implemented the fix in attach.go.

• Later commits capture updated conversation from the same session.
• Earlier snapshots stay unchanged.
• Reattaching to an already-attached commit is a no-op.
• Append-only transcripts get checkpoint-scoped token accounting.

The repro now passes on both backends. Lint and the full integration suite pass. The unit suite had one unrelated discovery failure that passed separately.

Changes are local and uncommitted.

Previously, attach checked “does this session already have a checkpoint?” If yes, it reused that checkpoint forever without rereading the conversation.

Now it checks “does this commit’s checkpoint already contain this session?”

• Yes: leave the existing snapshot unchanged.
• No: read the current transcript and attach a fresh snapshot to this commit, keeping earlier snapshots intact.

For append-only transcripts, it also compares against the previous snapshot so the new checkpoint counts only the additional tokens.

It reads the Entire-Checkpoint trailer from the current commit (HEAD), opens that checkpoint, and checks each stored session’s metadata for a SessionID matching the ID passed to attach.

A match means it’s already attached. No match means it adds the session; no checkpoint trailer means it creates a new checkpoint. This check uses the stored checkpoint metadata, so it still works if local session state has been deleted.

No—SessionID stays the same as you add turns. Checkpoints are snapshots of that session at different moments:

• Commit A → checkpoint 1 → session X, turns 1–3.
• More conversation happens; session is still X.
• Commit B → checkpoint 2 → session X, turns 1–6.

The check looks only inside the current commit’s checkpoint, not every checkpoint containing session X.

One limitation of this fix: if you add turns and rerun attach without making another commit, it leaves the existing snapshot unchanged.

Same session throughout: session X.

Before: both commits showed the first snapshot; turns 4–6 were missing.

After: commit A keeps its original snapshot, and commit B shows the conversation through turn 6.

I’ll run the required pre-commit checks, commit the fix, push it on a branch, and create a trail. Then I’ll check the trail’s findings.

I’ll include the before-and-after example in the trail body, showing the same session across both commits.

The branch is ready, and the trail draft includes the exact before-and-after table. Formatting and lint have passed; the required race-enabled test suite is still running before I commit.

The race-enabled unit and integration tests passed. The deterministic canary is running now—the last check before I commit and publish the trail.

All required checks passed, and the fix is committed as dcf3e6300c. I’m creating the trail now; that command also pushes the branch. The body includes your before-and-after example.

Committed and pushed dcf3e6300c.

Created trail #1467 with your before-and-after example in the body.

All local checks passed. No open findings currently; CI and agent review are running.

I’ll read the current trail body and copy it to the linked PR.

Updated PR #2642 to match the trail body, including the before-and-after example. Verified it saved correctly.

I’ll refresh the PR head and review the fix adversarially, focusing on retries, existing checkpoints, transcript changes, and token accounting. I’ll reproduce any suspected bugs before reporting them.

I’m using the live PR review skill to pin the current head and distinguish code findings from CI and review status.

I found a retry path that the new tests don’t cover: an initial attach can save a checkpoint and print its trailer without amending the commit. I’m testing whether a later attach -f incorrectly treats that unlinked snapshot as already captured. I’m also checking an existing review comment about external agents using byte offsets rather than line offsets.

Both issues reproduced. The retry regression fails on both backends and passes against the pre-change implementation. For the external-agent case, the documented byte-offset calculation returns the expected 20 tokens, while the line offset supplied by attach makes parsing fail and drops token usage. The review tests used temporary overlays; the checkout is unchanged.

Found two reproducible issues in PR #2642 at dcf3e6300c. I’d fix both before merging.

1. P2 — Retrying an unlinked attachment produces an empty scoped conversation.
   Run attach X non-interactively without -f, then retry with attach X -f. The first call saves a checkpoint but only prints its trailer. The retry creates another checkpoint and treats the entire conversation as previously captured, leaving the linked checkpoint with zero scoped messages and zero tokens. Raw transcript bytes remain available.
   Reproduced on both backends; the same test passes against the parent implementation. Preserve the pending checkpoint for retries. attach.go:248

2. P2 — External-agent token calculators receive the wrong offset unit.
   The new code passes a line count, while the external-agent protocol requires a byte offset. My fixture required byte offset 237; attach supplied 2, causing parsing to fail and token usage to become absent. Convert the boundary into the raw transcript’s byte offset for external calculators. attach.go:345

The checkout is unchanged. CI tests are green, but Entire Gates is blocked by an existing finding covering the retry issue.

I’ll refresh the PR comments and trail findings, add failing tests for the confirmed issues, then fix them. I’ll also check each remaining comment against the intended behavior before changing the code.

The PR comments also identify two review-session cases: repeating attach --review on the same checkpoint should be a no-op, and a later commit should allow a fresh review snapshot. I’ll add tests for both, while retaining the guard against converting an existing ordinary checkpoint into a review.

I’m adding regression tests for the retry, token-offset, and review-session bugs. Then I’ll run them against the current code to confirm they fail before applying the fixes.

The new tests reproduce all the reported failures: retries create an empty checkpoint, external-agent token counts disappear, and review snapshots either fail or lose their review metadata. I’ll bind retry recovery to the original commit and use the checkpoint’s stored metadata to decide whether a review attach is already complete.

All attach tests now pass, including a case where redaction changes the transcript’s byte length. Same-commit retries reuse the saved snapshot; later commits get fresh snapshots; review metadata is preserved. I’m running the repository-wide checks before publishing the update.

The PR still has the same three comments, and the changes cover each one. Lint flagged the growing runAttach function, so I extracted the receipt lookup and restarted validation.

Lint is clean, and the full race-enabled suite is running. The retry regression passes on both checkpoint backends; the review tests also confirm that an ordinary snapshot still cannot be converted into a review in place.

The focused tests and lint are green. The full suite is still running and has reported no failures so far; I’m waiting for it to finish before committing and pushing.

The unit and integration tests passed. A repository source guard flagged the hash comparison even though both values are strings; I made that explicit with a local variable and reran the full check.

The fixes and regression tests are staged. Lint is clean again; the full test rerun is the remaining pre-commit check. Once it passes, I’ll push the update and resolve the addressed trail finding and PR threads.

Unit and integration tests have passed, and the standalone pre-push lint is green. The deterministic E2E canaries are running now; no paid agent tests were used.

Pushed commit 586d27c25d to the PR. The full check passed, including both deterministic canaries. I’m checking the trail’s findings and resolving the feedback covered by this commit.

Fixed and pushed as 586d27c25d to PR #2642.

• Retries reuse the saved checkpoint.
• External agents receive correct byte offsets.
• Review attaches are idempotent and preserve metadata across commits.

Added failing regression tests first, then made them pass. mise run check and pre-push lint passed.

All three PR threads are resolved; the trail has no open findings.

I fixed the three PR comments and the additional trail finding:

1. Repeating attach --review failed. It now checks the session metadata stored in HEAD’s checkpoint. If it’s already a review, attach returns successfully without changing it—even when local session state is missing. Converting an existing ordinary snapshot into a review still errors.

2. External agents received the wrong token offset. Checkpoint metadata keeps a line offset, but external token calculators require bytes. I now convert that line boundary to a byte position in the raw transcript, so redaction changing the stored length cannot shift the offset.

3. Later commits could not capture review sessions. I removed the blanket rejection based on LastCheckpointID. A later commit can create a fresh review snapshot. Attaching without --review also preserves the session’s existing review kind, skills, and prompt.

4. Retrying before the trailer was added created another checkpoint. Attach now saves a receipt containing the original HEAD hash and checkpoint ID. A retry on that same HEAD reuses and links the saved snapshot; a different commit creates a new one.

Each bug has regression coverage. I confirmed the tests failed before the fixes and passed afterward.

I’ll check the current PR head, trail findings, and integration-test logs to identify what failed.

I’m using the live PR review skill to check the findings against commit 586d27c25d. There’s one new medium finding about transcript line offsets, and integration shard C failed; I’m tracing both before drawing a conclusion.

Shard C failed before the pre-push hook could start: Linux returned Text file busy while executing a test-created script. This points to a test-harness race, not an attach assertion failure.

The new finding assumes redaction can remove JSONL lines. The current redactor preserves them, and existing tests check that contract. I’m running those tests and retrying the failed CI checks.

The line-preservation and external-offset tests passed. The exact failing integration test also passed ten consecutive local runs. CI is retrying shard C on Linux; so far, the evidence points to a hook-execution flake, and I haven’t found a concrete defect behind the new line-offset finding.

Checked head 586d27c25d:

• One medium finding: appears non-actionable. JSONL redaction preserves line separators, and Codex sanitization retains the relevant records. The line-preservation and external token-offset tests passed. The finding remains open.
• Integration failure: shard C hit Text file busy executing a freshly written pre-push test hook—before the hook ran. This points to a test-harness flake, unrelated to attach. The exact test passed 10 consecutive local runs.

I restarted the failed CI checks; the Linux retry is still running. No code changes made.

I’ll check the CI retry and the trail’s current findings.

The integration retry passed, and all test/lint checks are green on 586d27c25d. That supports the earlier failure being a flaky hook-execution race.

Entire Gates is still red. One medium line-offset finding remains open—the same finding I assessed as non-actionable. No new findings.

I’ll resolve the line-offset finding with the validation evidence, then check that no findings remain open.

Resolved with the code and test evidence. Trail #1467 now has zero open findings.

I’ll check the trail’s current findings.

There are 3 new open findings on trail #1467, at 586d27c25d:

• High — retry recovery: a receipt referencing a deleted checkpoint blocks attach, even though HEAD never linked that checkpoint.
• Medium — missing previous snapshot: read errors abort attach instead of falling back to a full snapshot.
• Medium — hook-tracked sessions: attach updates the last checkpoint but leaves hook transcript/token boundaries unchanged, potentially causing duplicate capture later.

All three point to real gaps by code inspection. I haven’t reproduced them or changed code yet.

I’ll add failing regression tests for all three findings, implement the fixes, then run the required checks and update the PR.

All three regressions fail as expected: a missing receipt checkpoint blocks retries on both backends, prior-snapshot read errors abort capture, and attach changes hook-owned state. The tests also check that HEAD-linked checkpoints remain protected and cancellation errors still propagate.

The attach tests now pass. Missing pending checkpoints get a fresh ID and full snapshot; unavailable prefix data falls back to a full capture; and hook-checkpointed sessions are refused before attach changes their state. Reattaching an existing snapshot still succeeds unchanged.

Lint is clean. The full race-enabled test suite is running now, followed by the deterministic E2E canaries. The regressions also verify that refused attaches leave hook state and HEAD unchanged.

Unit and integration tests passed. The deterministic canaries are running, and I’m running the separate pre-push lint. I’ve also prepared matching PR and trail descriptions for the recovery behavior and hook-session restriction.