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

I hit this today on Windows 11 + Windows Terminal 1.24.11911.0 + PowerShell, Claude Code v2.1.216 (npm install, Bun single-file claude.exe), and did some digging that narrows the root cause further. Two findings that change the "possible solution" picture:

1. Windows Terminal already supports the needed protocol — the app just never asks for it

Windows Terminal implements win32-input-mode (DECSET 9001, spec). Once a client app emits ESC[?9001h, every keystroke arrives with full virtual-key + modifier state — no ReadConsoleInput or kitty protocol needed.

Verified with a raw-mode Node probe in the same WT tab:

Phase 1 (plain mode): press Shift+Enter
phase 1: hex[0d] str"\r"
Phase 2 (win32-input-mode): press Shift+Enter again
phase 2: str"^[[16;54;0;1;48;1_"      <- Shift keydown
phase 2: str"^[[13;28;13;1;48;1_"     <- Enter keydown, ctrl-state 0x30 = SHIFT_PRESSED|NUMLOCK
phase 2: str"^[[13;28;13;0;48;1_"     <- Enter keyup
phase 2: str"^[[16;54;0;0;32;1_"      <- Shift keyup

So the terminal side is fully capable: Enter-with-Shift is unambiguously distinguishable the moment the mode is enabled.

2. claude.exe half-implements this mode: it disables it on teardown but never enables it

Strings analysis of the v2.1.216 binary:

• "\x1B[?9001l" (disable) exists as a literal and is written on disconnect/teardown when the platform is Windows.
• Buffer.from("\x1B[?9001") exists, used in a stream filter that strips 9001h/9001l sequences.
• No ESC[?9001h (enable) exists anywhere in the binary, and no kitty protocol (CSI >u) or modifyOtherKeys sequences either.

So the input path never receives anything but a bare 0x0D for Shift+Enter, and no keybindings.json configuration can help — the information is discarded before the app ever sees it. The disable-on-teardown suggests win32-input-mode support was started but the startup enable never landed (or was removed).

Related: /terminal-setup currently reports "Shift+Enter is natively supported in Windows Terminal. No configuration needed." — which is misleading while the enable is missing. Same claim in the terminal-config docs.

Suggested fix

On Windows, when stdin is a ConPTY/VT terminal, emit ESC[?9001h at raw-mode startup and parse the ESC[Vk;Sc;Uc;Kd;Cs;Rc_ events (the 9001l teardown write is already there). WT ≥ 1.4 supports it; terminals that don't recognize the DECSET simply ignore it.

Workaround for other users hitting this

Make Windows Terminal translate Shift+Enter to a linefeed (\n = Ctrl+J), which is Claude Code's default chat:newline binding — works immediately, no Claude Code config needed. In WT settings.json:

"actions": [
  {
    "command": { "action": "sendInput", "input": "\n" },
    "id": "User.ShiftEnterNewline"
  }
],
"keybindings": [
  { "id": "User.ShiftEnterNewline", "keys": "shift+enter" }
]

Caveat: this applies to every app running in WT (e.g. it shadows PSReadLine's own Shift+Enter multiline binding), so it should be removed once Claude Code enables win32-input-mode itself.

Confirming this on Windows 11 (build 26200, version 25H2) + Windows Terminal 1.24.11911.0 + PowerShell 7.

/terminal-setup says Shift+Enter should work, but it still submits instead of adding a newline.

I tried @deganii's Windows Terminal workaround (remapping Shift+Enter to send a newline directly). It does fix Claude Code, but since that remap applies to the whole terminal, it also broke Shift+Enter in PowerShell: instead of inserting a new line at the cursor, PSReadLine inserted it above the current line. Had to undo the workaround because of that.

Using Ctrl+J or Ctrl+Enter for now, but would be great to see this fixed properly so Shift+Enter works without side effects elsewhere.

Still reproducing on v2.1.224 (winget build, claude.exe), Windows 11 26200 + Windows
Terminal 1.24.11911.0 + PowerShell 7. Re-ran @deganii's strings analysis against this
newer build: unchanged. ESC[?9001l is present, ESC[?9001h is not, and there is no
kitty push (CSI > <flags> u) anywhere — I searched every spelling including
template-constructed ones. So the missing enable is still missing four versions later.

Four things I can add that aren't in the thread yet.

1. The exact reason /terminal-setup misreports

supportsShiftEnter() checks the terminal against a table of terminals assumed to emit
CSI-u natively. In v2.1.224 that table is:

{
  ghostty: "Ghostty",
  kitty: "Kitty",
  "iTerm.app": "iTerm2",
  WezTerm: "WezTerm",
  WarpTerminal: "Warp",
  "windows-terminal": "Windows Terminal"   // <- incorrect
}

It backs getNativeCSIuTerminalDisplayName and is consulted alongside a separate list
of terminals that need setup (["vscode", "cursor", "windsurf", "alacritty", "zed"]).
Because windows-terminal sits in the first table, /terminal-setup short-circuits to
"Shift+Enter is natively supported in Windows Terminal. No configuration needed.", the
newline hint in the UI renders as shift+enter instead of ctrl+j, and no workaround is
ever offered.

That entry is wrong for every shipping Windows Terminal today: WT emits CSI-u only under
an extended keyboard protocol, and the app never requests one. Removing it is a
one-line change that would at least stop the tool from reporting success while the key
does nothing — which is the part that makes this so hard to diagnose. (This is also the
whole of #80817, which looks like a duplicate of this issue.)

2. The CSI-u decode path is already complete — only the negotiation is missing

Worth stating explicitly, because it narrows the fix: the input parser already handles
kitty-style CSI-u correctly. Keycode 13 maps to return, and the modifier parameter is
decoded as (param - 1) bitmask → shift / meta / ctrl / super. It also parses a kitty
keyboard response (CSI ? <flags> u), even though nothing ever sends the query.

You can confirm this end-to-end today by feeding it CSI-u by hand:

// Windows Terminal settings.json
"actions": [
  { "command": { "action": "sendInput", "input": "<ESC>[13;2u" },
    "id": "User.ShiftEnterCSIu" }
],
"keybindings": [
  { "id": "User.ShiftEnterCSIu", "keys": "shift+enter" }
]

where <ESC> is a JSON escape for U+001B: a backslash followed by u001b.

// ~/.claude/keybindings.json
{ "bindings": [ { "context": "Chat", "bindings": { "shift+enter": "chat:newline" } } ] }

This works. So everything downstream of the terminal handshake is done — the only gap is
that Claude Code never asks the terminal to send the disambiguated form.

(Note that both halves are required. Configuring only keybindings.json does nothing,
which is a common way to conclude the keybinding system is broken when it isn't.)

3. The sendInput workarounds break more than PSReadLine — including Codex CLI

@anton-ubi reported above that the "\n" workaround breaks PSReadLine's Shift+Enter. It
also breaks Codex CLI, and that case is worth spelling out because it doubles as
evidence for the proposed fix:

Codex CLI is a Rust/crossterm TUI. On Windows, crossterm reads Win32 console input
records, so it receives VK_RETURN with SHIFT_PRESSED directly and Shift+Enter works
with zero terminal configuration — same Windows Terminal, same PowerShell profile,
same session, default WT settings:

# ~/.codex/config.toml
[tui.keymap.editor]
insert_newline = ["ctrl-j", "shift-enter"]

A WT-level sendInput binding replaces the real key event with injected VT bytes, so it
regresses Codex to fix Claude Code. Anyone running both agents in one terminal has to
pick which one gets a working Shift+Enter.

Two implications:

• The workaround in this thread should carry a stronger caveat than "shadows PSReadLine".

It globally overrides Shift+Enter for every application in Windows Terminal, including
ones that already handle it correctly.

• **Suggested fix #1 in the issue body — read Win32 console input on Windows — is already

in production in a comparable tool on the same terminal.** It requires no terminal
configuration, no protocol negotiation, and works in conhost too, so it degrades better
than the 9001h route.

4. Windows Terminal Preview 1.25 probably does not fix this on its own

#80817 has a comment suggesting WT Preview 1.25 resolves it, citing the 1.25 release
notes' built-in kitty keyboard protocol support. I don't think that follows: the kitty
protocol is opt-in — the application must push flags with CSI > <flags> u — and
v2.1.224 emits no such sequence. Upgrading the terminal alone shouldn't change what
arrives on stdin.

It would be useful for someone who has actually verified it on WT Preview 1.25 to say
which Claude Code version they were on, since if it genuinely works, an enable is landing
somewhere I couldn't find it.

---

Happy to test a build with ESC[?9001h or a kitty push on WT 1.24 if that's useful.