[BUG] Session resume loses 80%+ of conversation — progress entries create parasitic forks in parentUuid chain

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33651
2. https://github.com/anthropics/claude-code/issues/34362
3. https://github.com/anthropics/claude-code/issues/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

Agreed that #33651 is the same root cause — progress entries creating parasitic forks in the parentUuid chain, walker follows the wrong branch. #34362 is also the same bug with bash_progress as the trigger.

Our case adds the hook-triggered variant (PreToolUse/PostToolUse progress entries rather than SubAgent/bash progress), plus diagnostic and repair scripts that others can use to verify and fix affected sessions.

Happy to close as duplicate of #33651 — but the diagnostic/repair scripts in this issue may be useful to link from there.

FYI my comment here https://github.com/anthropics/claude-code/issues/33651#issuecomment-4064080309 was mostly around the PreToolUse cause, and I have a repro: https://github.com/skevy/claude-code-pretooluse-chain-fork-repro

Root cause traced & working patch

Dug through the minified extension.js to trace the chain walker. One-line fix below, but the reasoning matters.

How the chain walker works

The session resume code reconstructs conversation history by:

1. Parsing JSONL into a UUID map — includes user, assistant, progress, system, attachment
2. Building a "has children" set — any UUID referenced as parentUuid by another entry
3. Finding leaf nodes — entries NOT in the "has children" set
4. From each leaf, walking backward through parentUuid to the nearest user/assistant
5. Picking the latest such entry as chain head, then walking the full chain backward
6. Filtering to user/assistant only (progress entries are discarded at this stage)

Where it breaks

The bug is in step 2. The leaf-detection set is built like this:

let K = new Set;
for (let D of j.values())
    if (D.parentUuid) K.add(D.parentUuid);

When a progress entry (hook event) has parentUuid = X, entry X gets marked as "has children" and is no longer a leaf candidate. If X happens to be the latest real conversation entry, the walker picks an earlier leaf and walks backward from there — everything after that point is gone.

Step 6 then filters progress out anyway. So progress entries participate in chain building just long enough to break it, then get thrown away.

This also explains @cacheoverflow-dev's finding in #24304 — progress entries with phantom parentUuids (from interrupted tool streams) create the same topology problem from the other direction: orphan parents that break the backward walk.

What doesn't work: removing progress from the parser

Tried this first. Fixes new sessions but breaks old ones — some old conversation entries have parentUuid pointing to progress entry UUIDs. Remove progress from the map and those backward walks hit undefined, truncating the chain.

What works: exclude progress from leaf detection only

Keep progress in the UUID map (backward walks still resolve through them), but don't let them mark conversation entries as non-leaves:

// before
let K = new Set;
for (let D of j.values())
    if (D.parentUuid) K.add(D.parentUuid);

// after
let K = new Set;
for (let D of j.values())
    if (D.parentUuid && D.type !== "progress") K.add(D.parentUuid);

One-line change. Progress entries still exist in the map for parentUuid resolution (old sessions work) — they just can't prevent real conversation entries from being leaves.

Tested on v2.1.78 with old sessions (containing progress entries) and new sessions (hooks active). Both _appear_ to load fully.

Patch script

Variable names change every build, so here's a script that auto-detects targets. Also includes the #29088 buffer fix (screenshot-started sessions invisible due to 64KB head read limit):

#!/bin/bash
# Patches Claude Code VSCode extension:
# 1. Session head/tail buffer 64KB -> 8MB (#29088)
# 2. Progress entries excluded from leaf detection (#35024)
# Re-run after each extension update.

EXT_DIR=$(ls -dt ~/.vscode/extensions/anthropic.claude-code-*-darwin-x64 2>/dev/null | head -1)
if [ -z "$EXT_DIR" ]; then
    echo "No Claude Code extension found"
    exit 1
fi

FILE="$EXT_DIR/extension.js"
VER=$(basename "$EXT_DIR")
PATCHES=""

[ ! -f "$FILE.bak" ] && cp "$FILE" "$FILE.bak"

# patch 1: buffer 64KB -> 8MB (#29088)
if ! grep -q '=8388608' "$FILE"; then
    VARS=$(python3 -c "
import re
with open('$FILE') as f:
    text = f.read()
for m in re.finditer(r'(\w+)=65536', text):
    start = max(0, m.start()-20)
    ctx = text[start:m.end()+50]
    if any(skip in ctx for skip in ['chunkSize','opcode','maxRate','Content-Type','HighWaterMark']):
        continue
    if '[0-9a-f]' in ctx or 'execFile' in ctx or 'return[]' in ctx:
        print(m.group(1))
")
    if [ -n "$VARS" ]; then
        SED_CMD=""
        for VAR in $VARS; do
            SED_CMD="${SED_CMD}s/${VAR}=65536/${VAR}=8388608/;"
        done
        sed -i '' "$SED_CMD" "$FILE"
        COUNT=$(grep -c '=8388608' "$FILE")
        PATCHES="buffer($COUNT vars)"
    fi
fi

# patch 2: progress fork fix (#35024)
if ! grep -q 'type!=="progress"' "$FILE"; then
    RESULT=$(python3 -c "
import re
with open('$FILE') as f:
    text = f.read()
m = re.search(r'let (\w)=new Set;for\(let (\w) of (\w)\.values\(\)\)if\(\2\.parentUuid\)\1\.add\(\2\.parentUuid\)', text)
if m:
    print(m.group(0))
    print(m.group(2))
")
    if [ -n "$RESULT" ]; then
        ORIGINAL=$(echo "$RESULT" | head -1)
        DVAR=$(echo "$RESULT" | tail -1)
        PATCHED=$(echo "$ORIGINAL" | sed "s/${DVAR}.parentUuid)/${DVAR}.parentUuid\&\&${DVAR}.type!==\"progress\")/")
        ORIG_ESC=$(printf '%s' "$ORIGINAL" | sed 's/[.[\(*^$+?{|]/\\&/g')
        PATCH_ESC=$(printf '%s' "$PATCHED" | sed 's/[&/\]/\\&/g')
        sed -i '' "s/${ORIG_ESC}/${PATCH_ESC}/" "$FILE"
        PATCHES="${PATCHES:+$PATCHES + }progress-fork-fix"
    fi
fi

[ -n "$PATCHES" ] && echo "$VER: patched $PATCHES — reload VSCode" || echo "$VER: already patched"

For Linux, change sed -i '' to sed -i. Buffer patch tested across v2.1.72–v2.1.78, full package tested on v2.1.78.

I love using claude to fix claude (NO)

Follow-up: orphan recovery patch

The leaf-detection fix from my earlier comment helps but doesn't catch everything. In long sessions with many tool calls, compaction boundaries and other fork sources can still leave conversation entries stranded — tested on a 1134-entry session where the leaf fix recovered ~50% but the other half was still orphaned.

Root cause (additional) ( FOR VERSION .79 )

The chain walker finds a leaf, walks backward through parentUuid, and returns that chain. Any user/assistant entries not reachable from the chosen leaf's backward path are silently dropped. Progress entries are one fork source, but compaction boundaries (compact_boundary system entries that rewrite parentUuid links) and interrupted tool streams create others.

Fix: orphan recovery as a safety net

After the chain walker builds its result, scan for any user/assistant entries that aren't in the chain and merge them back in by file position:

// after: return B.reverse()
// becomes:
var R = B.reverse(),
    S = new Set(R.map(function(e) { return e.uuid })),
    A = z.filter(function(e) {
        return !S.has(e.uuid)
            && (e.type === "user" || e.type === "assistant")
            && !e.isSidechain && !e.teamName && !e.isMeta
    });
if (A.length > 0) {
    R = R.concat(A);
    var P = new Map;
    for (var i = 0; i < z.length; i++) P.set(z[i].uuid, i);
    R.sort(function(a, b) { return (P.get(a.uuid) || 0) - (P.get(b.uuid) || 0) });
}
return R;

This is a no-op when the chain walker works correctly (A is empty). When it misses entries, they get merged back sorted by their original position in the JSONL.

Results on a real session

Original chain walker: 577/1134 conversation entries (50%)
With orphan recovery:  1134/1134 (100%)
Recovered: 557 orphaned entries

The updated patch script from my earlier comment now includes this as patch 3. Combined with the leaf-detection fix (patch 2), every session I've tested loads completely.

Losing 80%+ of conversation on resume because progress entries create parasitic forks is exactly what progress-collapse in Cozempic v1.4.1 fixes. It removes all progress tick messages that fork the parentUuid chain, and _relink_parent_chain() automatically repairs any broken links.

pip install cozempic && cozempic init

The guard runs progress-collapse automatically. You can also diagnose the issue first: cozempic doctor checks for corrupted parentUuid chains and orphaned tool results.

This was fixed in v2.1.85 — Progress messages are no longer written to the session transcript, fixing the resume bug where most of the conversation was lost to a forked message chain. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

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.