Session resume after 403 retry breaks parentUuid chain, losing entire conversation history #37437

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   area:core

   platform:linuxIssue specifically occurs on LinuxIssue specifically occurs on Linux

   data-loss

   on Mar 22, 2026
2. Loong0x00 commented on Mar 22, 2026

   

   Loong0x00

   on Mar 22, 2026

   Author

   More actions

   Additional Finding: No subagent was active when this occurred

   Upon further investigation, the user did not have any subagents running at the time of the bug. There was only a single main conversation window.

   The progress messages (L53703-53734) that corrupted the parentUuid chain were delayed writes from the previous conversation turn's tool calls — they were flushed into the JSONL after the turn_duration system message (L53699) had already marked that turn as complete.

   Revised timeline:

   1. L53699 — turn_duration written, marking the previous turn as "done"
   2. L53701 — User sends new message (correct parentUuid pointing to L53699)
   3. L53702 — API returns 403
   4. L53703-53734 — Previous turn's tool call results (progress type, containing web search results, file reads, etc.) are asynchronously flushed into the JSONL after their parent turn already ended
   5. L53736 — Retry picks up the last JSONL entry (a stale progress message) as parentUuid → chain broken

   Implications

   This means the bug is not limited to users who explicitly use subagents. Any conversation where internal tool calls (which are implemented as subagents under the hood) have async I/O can trigger this. The turn_duration marker does not await all pending writes before being emitted, so there is a window where stale progress messages can land between the turn boundary and the next user message.

   This significantly increases the blast radius — it can affect any session that hits a 403 during retry while prior tool-call results are still being flushed.
3. github-actions commented on Mar 22, 2026

   

   github-actionsBot

   on Mar 22, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] Session resume loses 80%+ of conversation — progress entries create parasitic forks in parentUuid chain #35024
   2. Session resume loses conversation messages when SubAgent progress chain overtakes main conversation chain #33651
   3. Conversation history missing on resume (except last message) #24304

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code
4. Loong0x00 commented on Mar 22, 2026

   

   Loong0x00

   on Mar 22, 2026

   Author

   More actions

   This is not a duplicate of the linked issues, though it shares the same root cause family.

   • Conversation history missing on resume (except last message) #24304 describes the symptom (history missing on resume) but attributes it to snapshot messageId collisions and orphan parentUuids
   • Session resume loses conversation messages when SubAgent progress chain overtakes main conversation chain #33651 identifies SubAgent progress chains as the cause
   • [BUG] Session resume loses 80%+ of conversation — progress entries create parasitic forks in parentUuid chain #35024 provides the most detailed structural analysis (fork points from progress entries)

   This issue adds a distinct trigger and deeper root cause analysis:

   1. 403 API error retry — the retries pick up the wrong parentUuid (last JSONL entry instead of the original parent), which none of the other issues document
   2. No subagent was active — the stale progress messages came from async-flushed tool call results from a previous turn, proving this affects all sessions with tool use, not just subagent sessions
   3. The turn_duration marker doesn't await pending writes — this is the architectural root cause that enables all variants of this bug

   The fix for all four issues is the same: the parentUuid chain walker needs to either (a) treat progress entries as sidechain, or (b) retry logic must preserve the original parentUuid. Both should probably be done.

   Requesting this not be auto-closed as duplicate — the trigger path and root cause detail here are complementary to the existing reports.
5. Loong0x00 commented on Mar 22, 2026

   

   Loong0x00

   on Mar 22, 2026

   Author

   More actions

   Source Code Analysis — Root Cause Found

   Decompiled the CC binary (2.1.81). The bug is in the tip-finding function used during session resume.

   The tip selector (ug$ in minified source):

   function findTip(messages, filter) {
     let tip, maxTime = -Infinity;
     for (let msg of messages) {
       if (!filter(msg)) continue;
       let t = Date.parse(msg.timestamp);
       if (t > maxTime) { maxTime = t; tip = msg; }
     }
     return tip;
   }

   This selects the message with the latest timestamp that passes the filter.

   The call site in giH (current session loader):

   let tip = findTip(messages.values(), (msg) => !msg.isSidechain);

   Filter: !isSidechain. That's it.

   The problem:

   progress messages have isSidechain: false, so they pass the filter. When progress messages are written asynchronously (e.g., from tool calls in the previous turn), their timestamps are later than the last real conversation message. The tip selector picks the progress message as the chain tip, then walkChain traces back via parentUuid through the progress branch, and the entire main conversation chain becomes unreachable.

   The fix is trivial:

   // Option A: filter by message type
   let tip = findTip(messages.values(), (msg) => 
     !msg.isSidechain && (msg.type === "user" || msg.type === "assistant")
   );
   
   // Option B: mark progress as sidechain when writing
   progressEntry.isSidechain = true;

   Either fix is a one-line change. Both should probably be applied.

   Why this wasn't caught:

   The SH_ (resume from file) and Yb (session list) code paths use leafUuids set for filtering, which may exclude progress messages depending on how leafUuids is populated. But giH (the live session loader) uses only the !isSidechain check — meaning this bug specifically affects live session resume (close window → reopen), not cold resume from file.

   This bug affects every session that has tool calls and gets resumed, not just subagent sessions or 403 retry scenarios. The 403 in my case just made the timing window wider, making it easier to trigger.

   This is the same root cause behind #35024, #33651, and #24304. One-line fix, open for 6+ weeks.
6. junaidtitan commented on Mar 22, 2026

   

   junaidtitan

   on Mar 22, 2026

   More actions

   We open-sourced cozempic which addresses part of this — it uses atomic writes (write→fsync→replace) so session files can't be partially corrupted during resume, and it never touches uuid/parentUuid fields so the conversation DAG stays intact. Feedback welcome.
7. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Apr 7, 2026
8. github-actions commented on Apr 21, 2026

   

   github-actionsBot

   on Apr 21, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
9. github-actions

   closed this as not plannedon Apr 21, 2026
10. github-actions commented on Apr 30, 2026

    

    github-actionsBot

    on Apr 30, 2026 – with GitHub Actions

    More actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
11. github-actions

    locked as resolved and limited conversation to collaborators on Apr 30, 2026