[Bug]: Claude rewind fails after a /compact that preserved recent messages, and leaves the forked transcript on disk #13638

Activity

1. juliusmarminge commented on Sep 25, 2026

   

   juliusmarminge

   on Sep 25, 2026

   Member

   More actions

   Triage

   Confirmed on current main (1c12706638) and on v0.0.42 (719a76ca1d). A Claude rewind whose fork drops a retained user or assistant message fails with this error, and the fork transcript is left on disk. No other open issue tracks it.

   What the report gets right

   Rewind does not truncate the source session. It calls the standalone forkSession(sessionId, { upToMessageId }), reads the fork back, and only then swaps the live session. The cut is the entry immediately before the first removed human turn, which is a trailing stop_hook_summary when Stop hooks are on:

         const rollbackAt = retainedCount > 0 ? messages[firstRemoved - 1]?.uuid : undefined;
         // ...
           const remappedBoundaries = remapClaudeForkTurnBoundaries(
             messages,
             forkMessages,
             firstRemoved,
             retainedBoundaries,
           );
           if (!remappedBoundaries) {
             return yield* new ProviderAdapterRequestError({
               provider: PROVIDER,
               method: "thread/rollback",
               detail: "Claude fork history did not preserve the retained turn boundaries.",
             });
           }

   #11954 only makes a length change acceptable when every retained user and assistant body is still present. System entries are ignored, so a trailing stop_hook_summary disappearing from getSessionMessages does not fail the check. A shorter conversation does:

   const remapClaudeForkTurnBoundaries = (
     messages: ReadonlyArray<ClaudeHistoryMessage>,
     forkMessages: ReadonlyArray<ClaudeHistoryMessage>,
     firstRemoved: number,
     retainedBoundaries: ReadonlyArray<string | null>,
   ): Array<string | null> | undefined => {
     const retainedConversation = messages.slice(0, firstRemoved).filter(isClaudeConversationMessage);
     const forkConversation = forkMessages.filter(isClaudeConversationMessage);
     // ...
     const offset = forkConversation.length - retainedConversation.length;
     if (
       offset < 0 ||
       retainedConversation.some((message, index) => {
         const forkMessage = forkConversation[index + offset];
         return (
           forkMessage === undefined ||
           forkMessage.type !== message.type ||
           !NodeUtil.isDeepStrictEqual(forkMessage.message, message.message)
         );
       })
     ) {
       return undefined;
     }

   offset === -1 with one missing assistant body is the reject path. The compact-prefix test is the opposite shape: the fork has extra earlier user/assistant messages and alignment from the end succeeds. A preserved assistant that getSessionMessages can no longer splice in is supposed to fail.

   That splice fails because of anthropics/claude-agent-sdk-typescript#472, still open. forkSession remaps message UUIDs and parentUuid, and copies compactMetadata (preservedSegment / preservedMessages) unchanged. The pinned SDK is 0.3.276. The report reproduces the helper on 0.3.274 and 0.3.280, so a newer lockfile does not clear this. v0.0.42 already contains the same error string.

   The failure returns before stopSessionInternal, which matches the adapter tests (closeCalls stays 0, the resume cursor is unchanged). The source thread is still the one the user had. The fork file is not. Nothing in the server calls deleteSession, and the history worker only implements getSessionMessages and forkSession. Each failed attempt writes another full copy and leaves it.

   What to be careful with

   resume + resumeSessionAt is the SDK's truncation API on the Agent SDK path, and this adapter deliberately does not send it. A stored resumeSessionAt is kept on the cursor and omitted from query() ("passes Claude resume ids without pinning a stale assistant checkpoint"). #7198 added a pin and was closed as superseded by #11338. The review note on that PR is already how main behaves: the cut comes from getSessionMessages, not from the empty in-memory turn list on a recovered session. Using resumeSessionAt means a new pin that startSession actually honors, cleared after the next message, not a reuse of the current cursor field.

   Cutting at the last retained assistant is the wrong general rule for that API. SDK 0.3.276 says to fork at the kept turn's last chain entry, whatever it is. The current messages[firstRemoved - 1] is that entry. It is a bad forkSession readback point when it is a system leaf, because getSessionMessages then drops it. resumeSessionAt accepts that UUID. Cutting earlier drops a kept-turn tool_result. This path is still untested against a preserved-segment compact, as the report says.

   Repairing preservedSegment inside the fork depends on the transcript layout the SDK bug is about. A fail-fast check before forkSession also cannot see that metadata on the desktop path: a distinct CLAUDE_CONFIG_DIR reads history through the worker, and decodeSessionMessages keeps only type, uuid, parent_tool_use_id, and message.

   Workaround

   Send the next message in the same thread, or start a new thread. Rewind did not stop the source session. The extra files are the rejected fork transcripts under the Claude project directory, not the session T3 is still resumed on.

   Labels / next

   • Type: bug, accepted.
   • Labels: bug, accepted.
   • Next: a rejected fork has to be removed with deleteSession (new worker method on the isolated-home path). Rewind after a preserved-segment compact stays broken until it stops using the standalone forkSession helper, or until Add run button for runnable markdown command code blocks #472 remaps compactMetadata. Prefer resume + a one-shot resumeSessionAt taken from durable history over editing the fork file. Do not send resumeSessionAt on an ordinary resume.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 25, 2026
3. cpakken commented on Sep 25, 2026

   

   cpakken

   on Sep 25, 2026

   More actions

   Reproduced on macOS arm64 (Darwin 27.0.0), T3 Code desktop nightly 0.0.43-nightly.20260925.2251.

   Local logs show four single-turn rollback failures across two Claude threads on September 25. Both threads previously emitted compact_boundary with preserved_segment and preserved_messages. One compaction was automatic; the other was manual.

   All four failed with: Claude fork history did not preserve the retained turn boundaries.

   This adds evidence that automatic compaction also precedes this failure. No application state or transcripts were modified during investigation.

   Investigated by Codex (GPT-6) via T3 triage.
4. juliusmarminge commented on Oct 2, 2026

   

   juliusmarminge

   on Oct 2, 2026

   Member

   More actions

   Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

   V2 rollback records a native conversation-head reference and resumes at that checkpoint. It no longer calls forkSession for rewind, removing the standalone fork UUID-remapping and rejected-copy mechanism in this report.

   I’m closing this report because the implementation it targets has been replaced. That does not mean every similar symptom is fixed.

   Source reviewed.

   Explicit fork still uses forkSession and is a separate action. No live preserved-compaction rewind was run.

   If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.
5. juliusmarminge

   closed this as not plannedon Oct 2, 2026