[BUG] claude agents: keyboard input (Esc/f/x) unresponsive after a /btw answer while the session's main task is still running
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
In claude agents, when I drop into a background session and it is actively working on a task (agent is thinking / calling tools / streaming a response), I sometimes ask a side question via the /btw overlay. /btw itself works and returns its answer. But after the /btw answer is shown, I cannot return to / interact with the session: keyboard input is unresponsive.
Esc(exit / go back) — ignoredf(fork) — ignoredx(delete history) — ignored- typing into the input — ignored
The input is effectively frozen for a while. It does eventually recover on its own — waiting gets me back control, and mashing keys only seems to "work" because one keystroke happens to land at the moment input resumes (it's the waiting, not the specific key).
What I'm NOT sure about: I can't say for certain what triggers the recovery. It correlates with the main task being in progress, so my best guess is that the input loop is blocked until the in-flight task yields/finishes — but I haven't verified that the unblock is tied precisely to task completion. It could be task completion, some intermediate yield point, or another timing factor. Treat the exact trigger as unconfirmed.
So the working hypothesis is: the /btw overlay (or its dismissal) leaves the session's input loop blocked while the main task is still running, instead of returning control to the session immediately — but the precise condition that releases it is not yet pinned down.
This is closely related to (but distinct from):
- #59814 / #60115 — input unresponsive after navigating back from a session (Windows), fixed in 2.1.144. I am on 2.1.145 and still hit this, but my trigger is specifically using
/btwinside an actively-working session, on Linux. - #59992 — FleetView freezes while
attachJobblocks the input loop (same class of "input loop blocked during background work"). - #45460 —
/btwre-executes after Ctrl+O during a subagent task (same/btw+ input-state area, different symptom).
What Should Happen?
After the /btw overlay answers, control should return to the session immediately and keyboard input should remain responsive even while the main task is still running — Esc, f, x, navigation and typing should all register without having to wait for the in-flight task. Asking a /btw question should never block my ability to leave or act on the session.
Steps to Reproduce
- Run
claude agents(Linux). - Drop into a background session that is actively working on a long task (agent thinking / calling tools / streaming output).
- While the task is still in progress, invoke
/btw <some side question>and let it return its overlay answer. - Try to interact with the session: press
Esc(exit),f(fork),x(delete history), or type into the input. - Observe: none of the keys register; the UI is frozen.
- Wait → input becomes responsive again on its own after a while. (Exact trigger of the recovery unconfirmed — see note above.)
Environment
- Claude Code version: 2.1.145
- Platform: Linux 6.8.0-90-generic
- TERM: xterm-256color
- Mode:
claude agents(FleetView), inside a background session
Error Messages/Logs
(no explicit error; purely an unresponsive-input / blocked-input-loop symptom)
6 Comments
This smells like the side-question overlay and the main task are sharing one control-state machine. If that's right, a small explicit state split like
main_task_runningplusoperator_interaction_resolvedwould be more robust than fixing individual key handlers, because the UI could route or disable keys based on truth instead of inferred view state.@Keesan12 thanks — your "shared control-state machine" framing actually made me re-read my own report and realize I'd overstated one thing, so I've just edited the description to correct it.
Specifically: I originally wrote that the input "unfreezes once the main task finishes processing." That was me inferring a causal link I haven't actually verified. What I can state factually is only that waiting recovers input (and that mashing keys just happens to land when it resumes). Whether the release is tied precisely to task completion, to some intermediate yield, or to another timing factor — I don't know. I've reworded the issue to flag the exact recovery trigger as unconfirmed, so nobody chases the wrong root cause based on my guess.
That said, your suggestion lines up well with the observable symptom: an explicit state split (e.g.
main_task_running+operator_interaction_resolved) routing/disabling keys on real state rather than inferred view state would be more robust than patching individual key handlers. If a maintainer wants, I'm happy to try to capture timing details (e.g. how long the freeze lasts vs. task duration) to help pin down the actual release condition.遇到同样的问题：macOS + VS Code 扩展，/btw 对话中发送一条消息后，等待 Claude 回复完毕，输入框无法再次输入，必须 Esc 关闭后重新 /btw 才能继续对话。
The macOS + VS Code extension report is a useful narrowing signal.
At this point it looks less like one broken key handler and more like a conversation/control-state release bug that happens to surface through different input widgets. The common invariant seems to be: after
/btwhas produced its reply, the side-thread should transition back to an input-enabled state exactly once, regardless of whether the host is the TUI or the VS Code extension.A good acceptance test here would be:
/btwreply completesIf the input only comes back after some later scheduler yield, that feels like a different bug class than a pure keybinding issue, and the new macOS repro makes that distinction much easier to justify.
Addressed by a merged fix. Please reopen with a fresh repro if you still see this on a current version.
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.