shift+enter keybinding for chat:newline not recognized on Windows Terminal

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.

Install 'Windows Terminal Preview' to temporarily solved this issue, or wait for 1.25 to be released; Of course, this is definitely a bug of /terminal-setup

Inputting your Inputs (better) Windows Terminal now ships with built-in support for Kitty‘s Keyboard protocol, which allows commandline applications to disambiguate keys such as Esc from Ctrl+[ and receive information about which modifiers were pressed. This allows applications to receive Shift+Enter among other things, which should improve your interaction with some modern “agentic” command line tools. https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-25-release/

This looks like a duplicate of #77311, which covers the same failure with the root cause
already narrowed down.

Short version of why the keybinding can't work: Windows Terminal sends a bare CR for
both Enter and Shift+Enter, and Claude Code never asks it for anything better — it emits
no win32-input-mode enable (ESC[?9001h) and no kitty keyboard push (CSI > <flags> u).
The Shift state is discarded before the app sees it, so no keybindings.json entry can
match. Confirmed still true in v2.1.224.

On the /terminal-setup misreport you flagged: the cause is that windows-terminal is
listed in the table of terminals assumed to emit CSI-u natively, alongside
Ghostty/Kitty/iTerm2/WezTerm/Warp. That makes supportsShiftEnter() return true, so the
command short-circuits to "no configuration needed" and the UI advertises shift+enter
as the newline hint. Details and the rest of the analysis are in
https://github.com/anthropics/claude-code/issues/77311#issuecomment-5262130898.

Re the WT Preview 1.25 suggestion above: I don't think a terminal upgrade fixes this by
itself. The kitty keyboard protocol is opt-in and v2.1.224 never pushes flags, so the
bytes arriving on stdin shouldn't change. If it does work for you on 1.25, could you say
which Claude Code version you were on? That would mean an enable exists somewhere I
couldn't find.

Suggest consolidating on #77311.