Repository navigation
[Bug] Resume flag reverts to pre-compaction state after manual compaction #14462
Closed as not planned
Description
Bug Description
i just compacted, ctrl^C twice then started claude with --resume with latest conversation. it went back to pre compaction state that i had to compact once more.
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.0.72
- Feedback ID:
Errors
[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/rasvi/.local/share/claude/versions/2.0.72 (expected in multi-process scenarios)\n at TZR (/$bunfs/root/claude:2428:2165)\n at yYA (/$bunfs/root/claude:2428:1885)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-12-18T12:24:18.197Z"},{"error":"Error\n at nk (/$bunfs/root/claude:59:1144)\n at <anonymous> (/$bunfs/root/claude:60:10097)\n at emit (node:events:92:22)\n at endReadableNT (internal:streams/readable:861:50)\n at processTicksAndRejections (native:7:39)\n at request (/$bunfs/root/claude:62:2149)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-12-18T12:24:18.597Z"},{"error":"Error\n at nk (/$bunfs/root/claude:59:1144)\n at <anonymous> (/$bunfs/root/claude:60:10097)\n at emit (node:events:92:22)\n at endReadableNT (internal:streams/readable:861:50)\n at processTicksAndRejections (native:7:39)\n at request (/$bunfs/root/claude:62:2149)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-12-18T12:24:18.597Z"},{"error":"RangeError: stdout maxBuffer length exceeded\n at unknown\n at onData (node:child_process:153:110)\n at emit (node:events:95:22)\n at addChunk (internal:streams/readable:264:47)\n at readableAddChunkPushByteMode (internal:streams/readable:242:18)\n at handleNumberResult (internal:streams/native-readable:69:18)\n at <anonymous> (internal:streams/native-readable:43:68)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-12-18T12:24:19.379Z"},{"error":"Error\n at nk (/$bunfs/root/claude:59:1144)\n at <anonymous> (/$bunfs/root/claude:60:10097)\n at emit (node:events:92:22)\n at endReadableNT (internal:streams/readable:861:50)\n at processTicksAndRejections (native:7:39)\n at request (/$bunfs/root/claude:62:2149)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-12-18T12:25:49.200Z"}]Reacted by Mint McQueen, Mitsuyuki Osabe and Jon Colverson
Activity
mintmcqueen commentedon Dec 24, 2025
Second this. Seems like the same issue as #14820
Significant impediment to functionality.
github-actions commentedon Jan 24, 2026
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
carrotRakko commentedon Jan 29, 2026
I can confirm this bug still exists in v2.1.23 and have done detailed analysis.
Reproduction Steps (detailed)
/compact(manual compaction)exitor Ctrl+Cclaude --resume <session-id>Observed Behavior at Data Level
I captured
.jsonltranscript snapshots at each step:/compact/compactexit--resumeKey Finding
When examining the transcript after resume:
parentUuidpointing to the last user message before compactioncompact_boundary, compact summary, and all post-compaction entries.jsonlfile, but the resume logic skips over itHypothesis
The resume logic appears to search for a "valid" anchor point to continue from. When it can't find one in the post-compaction entries (which are mostly user messages from
/compactcommand output), it falls back to the pre-compaction conversation.This is consistent with the original reporter's observation that "i had to compact once more" - the second compaction would produce a new valid anchor point.
Environment
✍️ Author: Claude Code (Dev Container) with @carrotRakko
Note: This comment was written and submitted by an AI agent (Claude Code), with human review and approval.
JJC1138 commentedon Feb 1, 2026
Just to confirm a workaround: If you send a message after compacting and wait for the response before exiting, then the compacted context is correctly saved when you resume.
github-actions commentedon Mar 2, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 10, 2026
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.