[BUG] chat:queueSubmit (Ctrl+X Enter) message is absorbed mid-turn instead of waiting for the turn to end

Description

The keybindings docs describe chat:queueSubmit (default Ctrl+X Enter) as: "Submit the message, marked to wait its turn: while Claude is working, Claude Code queues it and never interrupts the turn."

In v2.1.289, a message submitted with chat:queueSubmit is delivered at the next tool-call boundary within the same turn, the same as a plain Enter (chat:submit).

Steps to reproduce

1. Start claude v2.1.289 on macOS (tested inside tmux).
2. Send: Again: run "sleep 10; echo a", then "sleep 10; echo b", then "sleep 10; echo c" as three separate sequential Bash tool calls, then reply with exactly DONE2.
3. While the first sleep is running, type a message and press Ctrl+X Enter. The UI shows the message as queued with the hint ctrl+x ctrl+s to send now.
4. Inspect the session transcript's queue-operation entries.

Expected

The message stays queued until the turn ends (after DONE2), then is sent as the next turn.

Actual

After the next tool call finishes, the message is absorbed into the running turn. The third tool call then runs in the same turn:

{"op":"enqueue","ts":"2026-10-04T11:33:56.213Z","content":"CXMSG reply with exactly APPLE"}
{"op":"remove","ts":"2026-10-04T11:34:06.926Z","reason":"absorbed_mid_turn","content":"CXMSG reply with exactly APPLE"}

Binding chat:queueSubmit to tab in ~/.claude/keybindings.json gives the same result. The debug log shows that the binding loaded with 0 warnings:

{"op":"enqueue","ts":"2026-10-04T11:33:07.660Z","content":"TABMSG reply with exactly BANANA"}
{"op":"remove","ts":"2026-10-04T11:33:07.923Z","reason":"absorbed_mid_turn","content":"TABMSG reply with exactly BANANA"}

Environment

• Claude Code 2.1.289 (native install)
• macOS (Darwin 27.0.0), arm64
• tmux 3.7c
• Model: Haiku 4.5

Related

• #92988: Desktop has no equivalent of the CLI's chat:queueSubmit
• #93239: Enter interrupts instead of queueing