TUI hangs after `/compact` — input is blocked and the queued message is never sent

Summary

After running /compact in a very large session (~655k-token context on a 1M-window model), the TUI stopped accepting input: the message I typed afterwards stayed queued and could never be sent. The command never produced a visible result — no summary, no completion or error notice — and nothing released the prompt. I had to abandon the session and start a new one to keep working.

Simply put, when using fast compact-mode, super long conversations trigger compression failure, which can cause the session to break.

Expected Behavior

• /compact runs without blocking input: the prompt stays usable, and new messages are either accepted or queued and drained as usual once the pass finishes.
• A summarize pass that fails, times out, or has nothing to compact surfaces a notice (compaction failed / Conversation is already compact) and releases the input.
• When compaction succeeds, a compaction entry is appended to the session and any queued/steering message is delivered on the next turn.

Actual Behavior

• /compact (issued at 23:17:03 local, UTC+8) never completed: no compaction entry and no summary was ever written to the session transcript — verified in the .jsonl file: 0 compaction entries / isSummary messages.
• The input was dead: the message typed next could not be submitted; it stayed queued and was never delivered to the session.
• The process was still alive while the input was blocked: the transcript kept receiving turns (auto-continuation nudges + replies) from 23:17:06 through 23:22:31, i.e. 5+ minutes after the command.
• The only compaction accounting recorded afterwards is a 937-token automatic tool-call trim in the session meta at 23:20:49 (that session recorded 153 trim events in total; compact-mode was fast at the time).
• Recovery: a new session was created at 23:23:41 and the same message was sent there at 23:26:06. It never appears in the original session.

Steps to reproduce the issue

1. Work in a single session long enough that the context reaches several hundred thousand tokens. In my case: one session spanning 6 days (2026-09-10 → 2026-09-16), 1,382 transcript entries, model deepseek/deepseek-v4.1-flash (1M window, effort max), last request reported 655,598 input tokens; compact-mode = fast; 153 automatic compaction (tier-1 trim) events.
2. Run /context (it showed the high usage), then run /compact.
3. Try to type and submit a new message.
4. Observed: no result from the command, input cannot submit, the queued message is never sent — while background turns continue to be written to the session.
5. Workaround: start a new session; the same message sends normally there.

Command Code Version

1.54.2

Operating System

Windows

Terminal/IDE

Windows Terminal

Shell

cmd.exe

Session file (optional)

e557b148-0bb7-4b68-9049-b609b06d3dd2.meta.json

command-code-session-tail-redacted.json

Fix prompt (optional)

No response

Additional context

No response