Ctrl+B does not background the running command until the next keypress arrives (2.1.221)

Summary

Pressing Ctrl+B while a bash command is running does not background it. The UI stays on the running-command view. The backgrounding happens only when the next keystroke arrives, whatever that key is, at which point the task moves to the background and the second key is also applied normally (a plain character lands in the prompt, a bound key fires its binding).

So the Ctrl+B is not lost and it is not swallowing the next key: it appears to be queued and applied one input event late. The spinner and elapsed timer keep ticking normally while the press is pending, so the render loop is alive and this is not a stalled UI.

Reproduces every time.

Environment

• Claude Code: 2.1.221 (native install, latest channel)
• OS: macOS 15.7.7
• Terminal: iTerm2, TERM=xterm-256color
• No tmux, no screen: bare terminal, so no Ctrl+B prefix disambiguation is in play

Reproduction

1. Have Claude run a long bash command (e.g. sleep 60), so the running-command view with the ctrl+b to run in background hint is showing.
2. Press Ctrl+B once. Nothing happens. The command stays in the foreground and the hint stays on screen. The spinner and the elapsed-time counter keep updating.
3. Press any other key, e.g. the character x. The command now moves to the background, and x is inserted into the prompt input as usual.

Expected

The first Ctrl+B backgrounds the command immediately, with no second keystroke needed to flush it.

Actual

The first Ctrl+B has no visible effect. Its effect is applied when the next key is read, in addition to that key's own normal effect.

Notes

• Not the tmux double-press-to-send-prefix behavior: no multiplexer is running here, and the flushing key does not have to be Ctrl+B. Any key works.
• Not #69973 (Ctrl+B during the thinking phase): a real bash command is running here, and the press does eventually take effect.
• The combination of a live render loop plus a one-event-late application suggests the Ctrl+B handler updates state outside whatever the input reader uses to schedule a re-evaluation, so the pending background request sits until the next stdin event drives another pass.

Related

• #79036 (open): Agent View background-session input swallows the 1st Ctrl+b and applies two cursor moves on the 2nd. Different surface (cursor movement inside claude agents, not backgrounding), but the same swallowed-first-press shape, which may point at a shared input-layer cause.
• #46973 (closed): Ctrl+B backgrounds a running tool on a single press despite the UI showing a double-press requirement.
• #69973 (closed): Ctrl+B does nothing during the thinking phase, which looks identical to a running command.