Windows: Shift+Enter does not insert newline — terminal protocol limitation requires Win32 input support

Summary

On Windows, shift+enter is documented and configurable as a keybinding (e.g. chat:newline), but it does not work — it submits the message identically to plain Enter.

Environment

• OS: Windows 11 Enterprise
• Terminal: Windows Terminal (wt.exe) with Command Prompt profile
• Shell: cmd.exe (wt.exe cmd /k claude)
• Claude Code keybindings.json:

{
  "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
  "$docs": "https://code.claude.com/docs/en/keybindings",
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "shift+enter": "chat:newline"
      }
    }
  ]
}

Current Behavior

Pressing Shift+Enter submits the message, same as plain Enter. The keybinding is correctly configured but has no effect.

Expected Behavior

Pressing Shift+Enter should insert a newline (trigger chat:newline) rather than submit the message.

Root Cause

This is a terminal protocol limitation: in traditional VT terminals (including Windows Terminal's ConPTY layer), Shift+Enter and plain Enter both send the same byte (CR, 0x0D). The Shift key state is not transmitted, so Claude Code cannot distinguish them from the input stream.

Possible Solution

On Windows, the Win32 Console API (ReadConsoleInput) provides full key events including modifier state (SHIFT_PRESSED), which would allow distinguishing Shift+Enter from Enter. If Claude Code's Windows input handling were updated to use Win32 console input (or request an extended keyboard protocol such as the Kitty keyboard protocol from Windows Terminal), this distinction could be made reliably.

Impact

Users who want to use Shift+Enter as a newline shortcut on Windows cannot do so regardless of keybindings configuration.