## Description Shift+Enter no longer inserts a newline as of v2.1.91. This worked correctly in v2.1.87. This is a **new regression**, separate from #31371 (which was about v2.1.69–2.1.70). ## Steps to Reproduce 1. Install Claude Code v2.1.91 2. Open Warp terminal on macOS 3. Run `claude` 4. Type text, press Shift+Enter ## Expected Behavior A newline is inserted in the chat input. ## Actual Behavior The message is submitted (same as pressing Enter). ## Key Observation In the same Warp w

[BUG] Shift+Enter newline regression in v2.1.91 (works in v2.1.87, Warp terminal)

Status Fixed / completed

Reported on v2.1.70

Maintainer reply ✓ Yes — claude[bot]

Activity 7 comments · opened Apr 3, 2026 · closed Apr 17, 2026

💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

Description

Shift+Enter no longer inserts a newline as of v2.1.91. This worked correctly in v2.1.87.

This is a new regression, separate from #31371 (which was about v2.1.69–2.1.70).

Steps to Reproduce

Install Claude Code v2.1.91
Open Warp terminal on macOS
Run claude
Type text, press Shift+Enter

Expected Behavior

A newline is inserted in the chat input.

Actual Behavior

The message is submitted (same as pressing Enter).

Key Observation

In the same Warp window, tabs still running v2.1.87 have working Shift+Enter, while new tabs running v2.1.91 do not. This confirms the regression is in Claude Code's input handler between these two versions, not in Warp.

Additional Details

Adding shift+enter: chat:newline to ~/.claude/keybindings.json does not fix the issue.
/terminal-setup reports "Shift+Enter is natively supported in Warp" but it does not work.
Workaround: Ctrl+J still works for inserting newlines.

Environment

macOS (Darwin 25.4.0)
Warp terminal
Claude Code v2.1.91 (broken), v2.1.87 (working)

View original on GitHub ↗

7 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

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

vkartaviy · 5 months ago

Update: Setting the environment variable CLAUDE_CODE_NO_FLICKER=0 appears to fix the issue. Shift+Enter works correctly again in v2.1.91 with this flag.

This suggests the regression is related to the flicker-reduction rendering changes introduced in recent versions.

jesseparot · 4 months ago

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.

GuitaristForEver · 4 months ago

Can confirm that CLAUDE_CODE_NO_FLICKER=1 also breaks alt+delete (word deletion) in Warp terminal on macOS — not just Shift+Enter.

Environment:

Terminal: Warp
OS: macOS
CLAUDE_CODE_NO_FLICKER=1 set in ~/.claude/settings.json

Behavior:

alt+delete does nothing inside Claude Code input
Works correctly in regular Warp shell outside Claude Code

Fix:
Removing CLAUDE_CODE_NO_FLICKER from settings.json restores alt+delete word deletion immediately.

So the no-flicker renderer seems to be swallowing multiple key sequences in Warp beyond just Shift+Enter. May be worth investigating what other keybindings are affected by this rendering mode on Warp specifically.

sebryu · 4 months ago

FYI: seems like the problem is solved in 2.1.107 🎉 thanks @anthropic-team!

claude[bot] contributor · 4 months ago

This issue was fixed as of version 2.1.97.

github-actions[bot] · 4 months ago

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.