[BUG] Docs say Enter interrupts mid-task, but it only queues the message

Summary:
The documentation says pressing Enter while Claude Code is working should interrupt and steer it. In practice, Enter only queues the message — Claude Code continues its current task. This is a docs-vs-behavior mismatch.

Observed behavior:
In Claude Code (CLI), typing a message and pressing Enter while Claude Code is working does NOT interrupt it. Instead, the message appears as a "queued message" and Claude Code continues its current task. To actually interrupt and steer, the user must press Ctrl+C first, then Claude Code reads the queued message.

Expected behavior (per docs):
The official documentation under "Interrupt and steer" states:

"You can interrupt Claude at any point. If it's going down the wrong path, just type your correction and press Enter. Claude will stop what it's doing and adjust its approach based on your input. You don't have to wait for it to finish or start over."

Enter should interrupt Claude Code immediately — not just queue the message.

Either:

1. The behavior should match the docs (Enter interrupts mid-task), or
2. The docs should be updated to reflect the actual queuing behavior

Related issues:

• #30492 — Feature request for a priority message channel for real-time steering (same underlying problem, framed as a feature)
• #26388 — Queued messages get misinterpreted due to lost temporal context (closed/stale)
• #16905 — Esc key interrupt broken when queued messages exist

Steps to reproduce:

1. In Claude Code CLI, give Claude a task that triggers tool use (e.g., "look up the Claude documentation about X")
2. While Claude Code is executing tools, type a new message and press Enter
3. Observe: message shows as "queued" — Claude Code continues working
4. Press Ctrl+C to actually interrupt, then Claude Code reads the queued message

Environment:

• Claude Code: 2.1.79
• Terminal: tmux 3.6a
• Shell: zsh
• OS: macOS 26.3.1 (arm64)

🤖 Generated with Claude Code