[BUG] Shift+Enter no longer creates a new line in the input

Confirmed, WSL 2.1.70

Confirm this, macOS

Workaround: You can bind Alt+Enter to insert a newline via ~/.claude/keybindings.json:

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

Restart Claude Code after saving the file. Confirmed working on WSL2 with 2.1.70.

Yes, you can work around it, but it's mostly a muscle memory issue now 😅

Confirm on MacOs 26.2 (25C56). This drove me crazy today

Working on a proper fix.

In the meantime, what I see is that if there are older VSCode keybindings such as:

{
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\\\r\n"
        },
        "when": "terminalFocus"
    }

Then remove this, re-run /terminal-setup in claude, which should fix it with:

{
        "key": "shift+enter",
        "command": "workbench.action.terminal.sendSequence",
        "args": {
            "text": "\^[\r"
        },
        "when": "terminalFocus"
    }

I've found that at least on Alma Linux, VSCode->terminal->claude I can hold Alt and hit enter to get a soft newline that doesn't submit.

for me, ctrl+Enter works in WSL terminal.

In v2.1.71 (latest), only Option + Enter does work.
In v2.1.58 (stable version), Shift + Enter works fine.

The issue is fixed in v2.1.72.

Still there in 2.1.72

Encountered it today in v2.1.76, it did start occurring after upgrading to iTerm 3.6.9. Maybe people who are experiencing this issue are also on iTerm and could check their version with

mdls -name kMDItemVersion /Applications/iTerm.app

Update: also occurs in Terminal.app

Adding data from the duplicate #40015:

• Working version: 2.1.87 — Shift+Enter correctly inserts a newline in Warp terminal (macOS)
• Broken version: 2.1.91 — Shift+Enter submits the message instead

In the same Warp window, tabs still running v2.1.87 have working Shift+Enter, while new tabs running v2.1.91 do not — confirming the regression is in Claude Code's input handler.

Adding shift+enter: chat:newline to ~/.claude/keybindings.json does not fix the issue.

Confirming on macOS native app v2.1.91, running in Cursor's integrated terminal. Shift+Enter submits instead of inserting a newline. Initially suspected CLAUDE_CODE_NO_FLICKER=1 (fullscreen render), but disabling it (CLAUDE_CODE_NO_FLICKER=0) does not fix the issue.

Update: after further investigation, running cat -v in Terminal.app confirms Shift+Enter sends a plain CR (no ESC prefix) — the terminal itself is not sending a distinct key sequence. This started after upgrading to macOS 26.4 (Tahoe) on a new Mac (M5 Pro). The same shortcuts work fine in Warp, which encodes modifier keys differently. This may be a macOS-level regression in how Terminal.app handles modifier+key encoding, rather than (or in addition to) a Claude Code issue.

Was fixed in Claude Code 2.1.94 regressed again in 2.1.96

My Fix

Add this to your VS Code keybindings.json:

How to open: Cmd+Shift+P → type "Open Keyboard Shortcuts JSON" → select it

[
  {
    "key": "shift+enter",
    "command": "workbench.action.terminal.sendSequence",
    "args": {
      "text": "\^[\r"
    },
    "when": "terminalFocus"
  }
]

If you already have entries in the file, add the object inside the existing array.

What This Does

• Sends the escape sequence \^[\r (escape + carriage return) to the terminal when you press Shift+Enter
• This is what Claude Code interprets as "insert a new line" instead of "submit"
• The "when": "terminalFocus" ensures it only applies when the terminal is focused

Steps

1. Open keybindings.json (Cmd+Shift+P → "Open Keyboard Shortcuts JSON")
2. Paste the JSON above
3. Save
4. Restart VS Code (Cmd+Q, reopen)
5. Shift+Enter now inserts a new line in the terminal

Cleanup

If you added "chat.editor.newlineWithShiftEnter": true to your settings.json, remove it — it's not a valid setting.