[Bug] Esc key interrupt disabled when queued messages or background tasks exist

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/11803
2. https://github.com/anthropics/claude-code/issues/14526
3. https://github.com/anthropics/claude-code/issues/10537

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Still broken in v 2.1.2.
The only way to interrupt a prompt with background tasks is to kill Claude Code completely.

still broken in v 2.1.3
it's really dangerous and should be fixed with high priority

in 2.1.4 this has improved

Sometimes I still end up in a situation when I have to quit Claude Code to interrupt a prompt, but I can't reliably reproduce it.
EDIT: #17515 explains when this happens

can confirm 2.1.4 -> did not encounter the ESC ignoring bug anymore

Happened to me today.

Reproducing this in real-world use — long-running turns make the input effectively unusable

Hit this on macOS (Claude Code desktop app, Opus 4.8). Adding a concrete repro showing how impactful the "Esc disabled while messages are queued" behavior is in practice.

What happened:

• The assistant was running a long chain of Bash commands plus 3 background tasks. Each time a background task finished it re-invoked the model and extended the "turn in progress" state — so the session was continuously busy.
• During this I could type in the input box, but Enter would not send — the message just queued and never went out, because the turn never ended.
• Because messages were queued, Esc did not interrupt the running turn (it only moved queued text back into the input). No obvious way to recover from the UI.
• The only moment I could communicate was when the assistant called a tool that explicitly asks for input (a multiple-choice prompt) — the one point the app pauses for user input.
• Eventually even the home screen wedged: with a session stuck in "Needs input", I couldn't change the working folder for a new session. Required a full app restart (Cmd+Q).

Why this is bad UX:

• On large projects (a 1.3 GB repo with ~44 worktrees) turns take long enough that input is blocked for minutes. It looks like the app is frozen, when the message is just silently queued.
• There's no clear UI signal that "Enter won't send because a turn is running."

What would help:

1. Let Esc always interrupt the active turn, even when queued messages / background tasks exist.
2. Make it visually obvious when input is queued vs. sent (clear "queued — will send after current turn" indicator).
3. Consider letting a free-text message interrupt/steer the current turn rather than only queueing.
4. Don't let a single session in "Needs input" wedge the home screen (the folder picker should stay responsive).

Workaround: press Esc or the ⏹ Stop button to end the running turn; the input then frees up and Enter sends normally. If the whole app is wedged, Cmd+Q and reopen.

Env: Claude Code 2.1.83, macOS (Darwin 25.5.0, arm64 / Apple Silicon M4), model Opus 4.8.