[Bug] /clear command processes asynchronously, accepting input before completion
Status Fixed / completed
Reported on v2.1.112
Maintainer reply None cached
Activity 4 comments · opened Apr 19, 2026 · closed Apr 20, 2026
Bug Description
I did /clear then pasted some work. I got a note:
Session cleared. What would you like to work on?
It is as if the /clear had not worked until after I had pasted the text even though I see clearly the note for the initial clear
/clear
⎿ (no content)
Environment Info
- Platform: linux
- Terminal: kitty
- Version: 2.1.112
- Feedback ID: 8c955e27-a8b5-41e4-a5ab-51834ab03fe6
Errors
[{"error":"MaxFileReadTokenExceededError: File content (25575 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\n at fM7 (/$bunfs/root/src/entrypoints/cli.js:4720:12550)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-17T03:45:50.195Z"},{"error":"Error: EISDIR: illegal operation on a directory, read '/francisco-home/srht/pureawesome'\n at X_H (/$bunfs/root/src/entrypoints/cli.js:1564:144)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-18T03:58:26.340Z"},{"error":"Error: File does not exist. Note: your current working directory is /francisco-home/srht/pureawesome.\n at call (/$bunfs/root/src/entrypoints/cli.js:4729:7630)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-04-19T03:38:42.399Z"}]
4 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is a boundary-race bug in the
/clearlifecycle: the UI emits the semantic completion message ("Session cleared. What would you like to work on?") before the state transition has fully completed, so the user can paste input into what looks like a fresh session while stale context is still being cleared asynchronously.That is the worst possible order for a destructive/reset operation:
In other words,
/clearcurrently behaves more like "clear requested" than "clear completed," but the UI text promises the latter.This is the same family as several other timing/continuity issues we have seen: visible state advances before hidden state has actually caught up.
The invariant should be simple:
/clearmust be blocking from the user's perspective. No new input should be accepted until the clear operation has actually committed and the session is truly empty.If the implementation needs to remain async internally, then the UI should expose that honestly:
Right now the product is violating its own completion signal, which is why the user experience feels like the clear did not really happen when promised.
This seems to be duplicate of issues/32871. Closing this one.
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.