[BUG] Shift enter sends new message, instead of adding newline

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25054
2. https://github.com/anthropics/claude-code/issues/25104
3. https://github.com/anthropics/claude-code/issues/25057

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

2026-02-24 Still occurring in Claude Code 2.1.52 on Windows. [CTRL]+[ENTER] does work (for me).

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: A regression introduced in Claude Code v2.1.50 broke the Shift+Enter keybinding behavior. The keyboard input handling was changed so that Shift+Enter now triggers message submission (same as Enter) instead of inserting a newline character into the input buffer. This is likely caused by a change in the key event handler that either removed the Shift modifier check before submitting, or altered the keybinding map so Shift+Enter no longer maps to the 'newline' action. The bug is specific to the terminal input layer (Ink/React-based TUI) where key events are processed.

What worked for us:

The Shift+Enter key combination handler in the terminal input component needs to be restored to insert a newline instead of submitting the message. The key event handler should check for the Shift modifier and, when present with Enter, insert '\n' into the input buffer rather than triggering the submit action. This was working in v2.1.49 and regressed in v2.1.50, so the fix involves reverting or correcting the key handling logic that changed between those versions.

Steps:

1. Identify the input component that handles key events (likely in the Ink-based TUI input handler)
2. Locate the Enter key handler and verify that it checks for the Shift modifier (event.shift or similar)
3. Ensure Shift+Enter inserts a newline character into the input text instead of calling the submit/send function
4. Verify the fix works across different terminal emulators (iTerm2, Terminal.app, IntelliJ IDEA terminal, VS Code terminal) as Shift+Enter escape sequences can vary by terminal
5. Note: Some terminals send different escape sequences for Shift+Enter — the fix may need to handle multiple sequences (e.g., \x1b[13;2u for kitty protocol, or plain \r with shift flag)

// In the key event handler (pseudocode showing the expected logic):
// The handler should differentiate Shift+Enter from plain Enter:

if (key === 'return' && input.shift) {
  // Insert newline into input buffer
  insertTextAtCursor('\n');
} else if (key === 'return') {
  // Submit the message
  handleSubmit();
}

// If using Ink's useInput hook:
useInput((input, key) => {
  if (key.return && key.shift) {
    // Add newline - DO NOT submit
    setText(prev => prev + '\n');
    return;
  }
  if (key.return) {
    onSubmit(text);
  }
});

📊 _We found 4 similar cases in our knowledge base with the same pattern — this gives us high confidence in this analysis._

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

---
_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

2026-03-04 Still occurring in Claude Code 2.1.68 on Windows. [CTRL]+[ENTER] does work (for me).

Workaround: Shift+Enter for newline in Claude Code on Windows Terminal

Verified working on:

• Windows 11 Pro (10.0.26200)
• Windows Terminal 1.23.20211.0
• Claude Code 2.1.70

The root cause is that Windows Terminal sends the same byte (CR) for both Enter and Shift+Enter — the terminal can't distinguish them. The fix requires two changes:

1. Windows Terminal — teach it to send a distinct escape sequence for Shift+Enter

In %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json, add to actions:

{
    "command": {
        "action": "sendInput",
        "input": "\^[[13;2u"
    },
    "id": "User.sendInput.ShiftEnter"
}

And add to keybindings:

{
    "id": "User.sendInput.ShiftEnter",
    "keys": "shift+enter"
}

2. Claude Code — map Shift+Enter to newline

In ~/.claude/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"
      }
    }
  ]
}

Restart Windows Terminal after both changes. Shift+Enter will insert a newline, Enter will send — matching Claude.ai and Claude Desktop behavior.

Still broken

Update: removed my keybinding json and did /terminal-setup now works again.

Update: removed my keybinding json and did /terminal-setup now works again.

This was exactly my problem. It seems claude code changed the newline command, from "\\\r\n" to "\^[\r", but didn't migrate existing installs correctly.

Same issue on Windows Terminal. A terminal-side workaround (configuring sendInput with Kitty escape sequence \^[[13;2u for shift+enter) works for Claude Code, but breaks other CLI tools (e.g. Codex CLI which doesn't support the Kitty keyboard protocol). Claude Code should opt-in to the Kitty keyboard protocol itself.

Adding evidence that this may also affect clean installs, not just users with stale keybinding configs:

Background

I tested this both in my normal macOS and in a clean macOS user account (latter with only Claude Code installed, no custom shell config)

Repro 1: fresh terminal

1. zsh -f (meaning no rc files, no plugins, bare shell)
2. claude
3. Shift+Enter -> submits the prompt

Repro 2: clean macOS user account w/ nothing installed except Claude Code:

1. Open iTerm2, new window
2. claude
3. Shift+Enter -> submits the prompt
4. exit
5. claude again in the same window no config change
6. Shift+Enter → inserts newline ✅
7. Close and reopen iTerm2 → back to failing

Observations

Running cd/ls between launches doesn't appear to fix the problem. Only a prior claude session does. That points to a race condition in the Kitty protocol handshake rather than shell warmup. The first session appears to leave the terminal in Kitty protocol mode, second inherits it.

해결 방법: Windows 터미널에서 Claude Code를 사용할 때 Shift+Enter 키를 눌러 줄 바꿈을 합니다. 다음 기기에서 정상 작동 확인됨: 윈도우 11 프로 (10.0.26200) 윈도우 터미널 1.23.20211.0 * 클로드 코드 2.1.70 근본적인 원인은 Windows 터미널이 Enter 키와 Shift+Enter 키에 대해 동일한 바이트(CR)를 전송하기 때문입니다. 터미널은 이 둘을 구분할 수 없습니다. 해결하려면 두 가지 사항을 변경해야 합니다. 1. 윈도우 터미널 - Shift+Enter 키 조합에 대해 별도의 이스케이프 시퀀스를 전송하도록 설정 에 %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json다음을 추가하세요 actions: { "command": { "action": "sendInput", "input": "\^[[13;2u" }, "id": "User.sendInput.ShiftEnter" } 그리고 다음을 추가하세요 keybindings: { "id": "User.sendInput.ShiftEnter", "keys": "shift+enter" } 2. 클로드 코드 - Shift+Enter를 줄바꿈으로 매핑 안에 ~/.claude/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" } } ] } 두 가지 변경 사항을 모두 적용한 후 Windows 터미널을 다시 시작하십시오. Shift+Enter를 누르면 줄 바꿈이 삽입되고, Enter를 누르면 —가 전송됩니다. 이는 Claude.ai 및 Claude Desktop의 동작 방식과 동일합니다.

This method worked for me. Thank you so much.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.