[Bug] Premature message compaction at low token usage threshold
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 11 comments · opened Nov 18, 2025 · closed Mar 5, 2026
Bug Description
Compaction happens on 1m sonnet 4.5 and 4% of the session token usage as well as 24% of the context still left.
Environment Info
- Platform: darwin
- Terminal: WarpTerminal
- Version: 2.0.43
- Feedback ID: b64565be-9007-4c99-9c84-24d00e7fa2d3
Errors
[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.42 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async ZtR (/$bunfs/root/claude:2254:3329)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:32:51.780Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:33:05.676Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:35:30.461Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:35:33.888Z"},{"error":"Error: Request was aborted.\n at _createMessage (/$bunfs/root/claude:393:4515)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:36:25.725Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:44:19.443Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:45:27.122Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:50:41.812Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T02:53:59.567Z"},{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/kirso/.local/share/claude/versions/2.0.43 (expected in multi-process scenarios)\n at epB (/$bunfs/root/claude:2254:1514)\n at JtR (/$bunfs/root/claude:2252:12596)\n at async B5_ (/$bunfs/root/claude:2252:13802)\n at async iS (/$bunfs/root/claude:2254:235)\n at async <anonymous> (/$bunfs/root/claude:2254:12373)\n at processTicksAndRejections (native:7:39)","timestamp":"2025-11-18T03:03:00.457Z"},{"error":"Error: Request was aborted.\n at makeRequest (/$bunfs/root/claude:669:3861)\n at processTicksAndRejections (native:7:39)","timestamp
Note: Error logs were truncated.
<img width="1186" height="800" alt="Image" src="https://github.com/user-attachments/assets/29c67269-6efa-4525-ad66-2afcf3c892d3" />
<img width="1930" height="1052" alt="Image" src="https://github.com/user-attachments/assets/418eb7d6-46c0-471c-968e-e9f712d23685" />
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I also have this kind of BUG when are they going to fix it?
I’m running multiple sub-agents in parallel. If any one of them fails with this error, the entire process becomes unrecoverable. I'm not aware of any mechanism to retry, isolate, or recover from the failure.
Please help.
this bug has existed for a good 2 months already
This is really weird
<img width="766" height="134" alt="Image" src="https://github.com/user-attachments/assets/6e9a6b6f-8f23-4942-bfa7-c9d509bf1c34" />
<img width="696" height="278" alt="Image" src="https://github.com/user-attachments/assets/4ba99b0d-3d5a-432f-885c-ad5418c32eed" />
Had that too, as a workaround I used
/resumeand restored one message behind of(current)to recover from the infiniteRun /compact to compact & continuebugseems like this bug got worse or is getting worse than before
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.
Yes, still happening, very frustrating, and time-wasting.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.