You press Shift+Enter in Claude Code expecting a new line, and instead your half-finished prompt is submitted:
> Refactor the auth module and
[message sent]
The shortcut is not broken and your install is fine. In most terminals Shift+Enter is indistinguishable from Enter unless the terminal is explicitly configured, so Claude Code never sees a separate keypress to act on.
Why This Happens
Terminals communicate with programs through control sequences, not key events. By long-standing convention, pressing Enter sends a carriage return (\r). Most emulators send that same \r when you hold Shift, because historically there was no reason to distinguish them.
So Claude Code receives one byte and cannot tell whether Shift was held. It does the only sensible thing with a carriage return at the end of a prompt: it submits.
Fixing this means configuring the terminal to send something different for Shift+Enter — specifically an escape followed by a return (\x1b\r) — which Claude Code recognises as "insert a newline".
Three environments behave differently:
- Terminals with native support — already send a distinct sequence. Nothing to do.
- VS Code-family editors and iTerm2 — can be configured, which is what
/terminal-setupdoes. - Inside tmux or screen — the multiplexer rewrites sequences before they reach Claude Code, which breaks detection.
Fix 1: Use Backslash + Return (Works Everywhere, Right Now)
Before configuring anything, know that Claude Code already has a universal multi-line input method:
> Refactor the auth module and \
add tests for the token refresh path
Type a backslash (\) and press return. The line continues instead of submitting. This needs no setup, works in every terminal including tmux and over SSH, and is unaffected by anything below. If you only occasionally write multi-line prompts, you can stop here.
Fix 2: Check Whether Your Terminal Already Supports It
These terminals support Shift+Enter natively:
- iTerm2
- WezTerm
- Ghostty
- Kitty
- Warp
- Windows Terminal
If you are using one of them and Shift+Enter still submits, the cause is almost certainly a multiplexer (see Fix 4) or a custom key mapping in your terminal profile that overrides the default. Running /terminal-setup in a terminal that already works is unnecessary.
Fix 3: Run /terminal-setup
For everything else, Claude Code will install the keybinding for you. From inside a Claude Code session:
/terminal-setup
This configures the Shift+Enter shortcut for multi-line prompts. It supports:
- IDEs: VS Code, Cursor, Devin Desktop, Zed
- Terminal: iTerm2
Two conditions must hold for it to work:
- Run it in the terminal you actually want configured — for an IDE, that means the editor's own integrated terminal, not a separate terminal app.
- Run it directly, not inside tmux or screen.
Restart the terminal after it finishes so the new keybinding is loaded.
Fix 4: Exit tmux or screen First
Terminal multiplexers intercept and re-encode key sequences on their way through. /terminal-setup cannot detect or configure the real emulator from inside one, and even a correctly configured emulator may have its Shift+Enter sequence rewritten in transit.
The sequence is:
# Detach from tmux
# (Ctrl-b then d, or Ctrl-a then d depending on your prefix)
# Run Claude Code directly in the terminal
claude
# then: /terminal-setup
# Reattach afterwards
tmux attach
If you live in tmux permanently, add a passthrough binding to ~/.tmux.conf so the sequence survives:
bind -n S-Enter send-keys Escape "Enter"
Reload with tmux source-file ~/.tmux.conf. If that proves fiddly, backslash + return from Fix 1 works inside tmux with no configuration whatsoever.
Fix 5: Add the VS Code Keybinding Manually
If /terminal-setup fails — commonly on VS Code Remote, in dev containers, or where settings are managed — add the binding yourself.
Open the command palette and choose Preferences: Open Keyboard Shortcuts (JSON), then add this entry to the array:
{
"key": "shift+enter",
"command": "workbench.action.terminal.sendSequence",
"args": { "text": "\u001b\r" },
"when": "terminalFocus"
}
The file must be a valid JSON array, so add a comma after the preceding entry if there is one. The \u001b\r value is escape followed by carriage return — exactly the sequence Claude Code interprets as a newline. This is the same entry /terminal-setup writes for you.
The same entry works in Cursor and other VS Code forks, since they share the keybindings format.
On a remote connection this must be done locally. With VS Code Remote-SSH or a dev container, the keyboard is handled by the VS Code window on your own machine, so edit keybindings.json there rather than inside the remote session. This is the single most common reason a manual edit appears to do nothing.
Verify the Fix
Restart your terminal or IDE, start Claude Code, and type a few words followed by Shift+Enter. You should see the cursor drop to a second line with your text still unsent. Type more, then press Enter alone to submit.
If it still submits, work through this order:
- Are you inside tmux or screen? Exit and retest.
- Are you connected remotely? Confirm the keybinding is on the local machine.
- Did you restart the terminal after the change?
- Does another extension or profile already bind
shift+enter? Search your keyboard shortcuts for conflicts.
Prevention
- Use a terminal with native support. If you have a free choice, iTerm2, WezTerm, Ghostty, Kitty, Warp and Windows Terminal all work with no configuration on any machine you sit down at.
- Learn backslash + return anyway. It is the one method that works everywhere — over SSH, in tmux, in a container, on a colleague's laptop.
- Paste long prompts. Composing in an editor and pasting the block in is often faster than typing multi-line input at the prompt, and newlines in pasted text are preserved.
- Re-run /terminal-setup after switching editors. The keybinding lives in the editor's configuration, so a new IDE means running it again.