[BUG] Desktop app (Windows) Code tab: Ctrl+Enter during a text-only response queues instead of send-now (app 2.31226.1.0, runtime 2.1.295)

Environment

• Claude Desktop (Windows 11 Home 10.0.26200), package Claude 2.31226.1.0 (MSIX), Code tab
• Bundled Claude Code runtime running the session: 2.1.295 (%APPDATA%\Claude\claude-code\2.1.295\…\claude.exe, confirmed from the running process path)
• Standalone CLI also installed: 2.1.296 (separate binary; not involved)
• ~/.claude/keybindings.json: absent (engine defaults). ~/.claude/settings.json: autoUpdatesChannel: latest, no queue-related keys.

Expected

Per https://code.claude.com/docs/en/interactive-mode#queue-messages-while-claude-works and the 2.1.275 / 2.1.281 changelog entries: Enter while Claude works queues the message; Ctrl+Enter (or Ctrl+X Ctrl+S) sends now — interrupting a text-only response, or moving running tools to the background. The 2.1.292 changelog mentions "Send now in the desktop app".

Observed (independent reproduction, dedicated test conversation, harmless canary text only)

| Step | Result |
|---|---|
| Idle Enter: ask for a 250-line numbered list | response streams (PASS) |
| Type a canary while it streams | draft stays editable, response continues (PASS) |
| Enter during the long text response | row shows 1 message queued; the list runs to line 250, then the canary is answered once (PASS for queue) |
| Ctrl+Enter during a second long text response, canary CTRL_ENTER_CANARY_B | row shows 1 message queued; the response continues from ~line 68 to 250 and only then is the canary answered. Nothing is sent now. |
| Esc during a third long response with a draft | response stops; draft kept, not submitted (PASS) |

So on this surface Ctrl+Enter behaves exactly like Enter (queue), never like send-now.

Notes from a read-only look at the installed app (no patching)

• app/.vite/renderer/main_window/index.html says the Code-tab UI is loaded from claude.ai at runtime; the composer's key handling is therefore not in the local package and keybindings.json (chat:sendNow) cannot reach it.
• The local main process holds a mid-turn message as a "steered" message and delivers it at the next turn boundary (after a tool call, or a thinking-only cut), and separately exposes LocalSessions.sendSteeredNow(sessionId, uuid) ("re-sent at priority now", telemetry desktop_ccd_midturn_send mode send_now). During a long text-only response there is no boundary, so unless the UI calls sendSteeredNow the message waits for the whole text. On this build Ctrl+Enter did not trigger it.

Ask

Either make Ctrl+Enter in the Desktop Code-tab composer call the host's send-now (and interrupt a text-only response like the terminal does), or document that send-now in the Desktop app is only available through the queued-message row control / only during tool calls, and name the gesture. Happy to re-test on request.