Bug Description
2.1.282: input box stops accepting keystrokes ~30 s into every session (2.1.281 fine)*
Summary
Since 2.1.282, every interactive session stops taking keyboard input within 0–90 s. This happens mid-typing. Nothing redraws, and Ctrl-C does nothing. The process stays alive at ~0% CPU and keeps sending presence/heartbeat pulses, so it hasn't crashed or hung: the input box has been disconnected. Rolling back to 2.1.281 (same config, same folder, same terminal) fixes it completely.
Environment
- Claude Code 2.1.282 native install. 2.1.281 is the last good version.
- FreeBSD 15.1-RELEASE with Linux binary compatibility (the Linux build runs under the Linuxulator)
- Konsole, TERM=xterm-256color, launched with
--dangerously-skip-permissions, env BUN_JSC_useBBQJIT=0
Evidence
- On 2026-09-24, 11 sessions on 2.1.282 each went unresponsive within 0–90 s. That includes sessions after a reboot and sessions run with a stripped config (no hooks or plugins). 2.1.281 sessions run for hours.
- Reproduced with
--debug. Keystrokes render until 01:30:50Z, then:
01:30:54.427Z Fast mode unavailable: Fast mode requires usage credits
01:30:54.433Z prompt.edit: unhooked; the composer relays nothing
01:30:54.438Z AutoUpdaterWrapper: Installation type: native
01:30:54.439Z [FileIndex] getProjectFiles called, respectGitignore=true
After this only presence pulses and heartbeats appear. No further input is processed.
(prompt.edit: unhooked also appears at startup in every 2.1.282 log, so it may not be the trigger.)
- The first repro log shows
fullscreen boot canary: healthy, which suggested the new fullscreen trial, but see the next section: disabling the alternate screen does not fix it.
- Thread snapshot while frozen: all threads idle in
futex/kqread/select, 0.2% CPU.
Test with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1
Still freezes. With CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 the log has no fullscreen lines at all. A prompt ran to completion ([engine] turn 1 end ... stop=end_turn at 01:36:11.033Z, result rendered), ~/.claude.json was written at 01:36:11.061Z, and from then on no keystroke registered: only heartbeats. So the freeze happens with or without fullscreen, either mid-typing (run 1) or right after a turn ends (run 2).
Attachments: full debug log 2.1.282-freeze-debug.txt, thread snapshot 2.1.282-freeze-threads.txt, second run log 2.1.282-freeze2-noaltscreen-debug.txt
Environment Info
- Platform: linux
- Terminal: konsole
- Version: 2.1.281
- Feedback ID: 072a8761-a554-4db0-83d6-a276bc2da386
Errors
Bug Description
2.1.282: input box stops accepting keystrokes ~30 s into every session (2.1.281 fine)*
Summary
Since 2.1.282, every interactive session stops taking keyboard input within 0–90 s. This happens mid-typing. Nothing redraws, and Ctrl-C does nothing. The process stays alive at ~0% CPU and keeps sending presence/heartbeat pulses, so it hasn't crashed or hung: the input box has been disconnected. Rolling back to 2.1.281 (same config, same folder, same terminal) fixes it completely.
Environment
--dangerously-skip-permissions, envBUN_JSC_useBBQJIT=0Evidence
--debug. Keystrokes render until 01:30:50Z, then:(
prompt.edit: unhookedalso appears at startup in every 2.1.282 log, so it may not be the trigger.)fullscreen boot canary: healthy, which suggested the new fullscreen trial, but see the next section: disabling the alternate screen does not fix it.futex/kqread/select, 0.2% CPU.Test with
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1Still freezes. With
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1the log has no fullscreen lines at all. A prompt ran to completion ([engine] turn 1 end ... stop=end_turnat 01:36:11.033Z, result rendered),~/.claude.jsonwas written at 01:36:11.061Z, and from then on no keystroke registered: only heartbeats. So the freeze happens with or without fullscreen, either mid-typing (run 1) or right after a turn ends (run 2).Attachments: full debug log
2.1.282-freeze-debug.txt, thread snapshot2.1.282-freeze-threads.txt, second run log2.1.282-freeze2-noaltscreen-debug.txtEnvironment Info
Errors