[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) — ignored
• f (fork) — ignored
• x (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 /btw inside an actively-working session, on Linux.
• #59992 — FleetView freezes while attachJob blocks the input loop (same class of "input loop blocked during background work").
• #45460 — /btw re-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

1. Run claude agents (Linux).
2. Drop into a background session that is actively working on a long task (agent thinking / calling tools / streaming output).
3. While the task is still in progress, invoke /btw <some side question> and let it return its overlay answer.
4. Try to interact with the session: press Esc (exit), f (fork), x (delete history), or type into the input.
5. Observe: none of the keys register; the UI is frozen.
6. 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)