Suggestion: Don't auto-submit on `Enter`, makes it difficult to write multiple lines

I would humbly disagree - this is expected behavior for a terminal application and IMHO should stay as is - any changes to that behavior should be optional config or behind a feature flag IMHO

@asgeo1 there is already a config for this (well, not exactly what you ask for, but something that's more convenient than backslash-enter), see /terminal-setup (but it only works for some setups, like VS-Code)

/terminal-setup | Install Shift+Enter key binding for newlines (iTerm2 and VSCode only)

Link

Thanks for the suggestion @asgeo1. We don't currently plan to change the default Enter key behavior. Does Shift+Enter work as an alternative for adding new lines work for your workflow? Let us know if that addresses your concern.

@rboyce-ant do you think it would be possible to patch the /terminal-setup so work for VS-Code Insiders as well? cuz there's two different keybindings for Code/Code Insiders

Yes I would be happy with shift-enter - I did try that before but sadly doesn't work for me using kitty + fish, it just submits the question.

/terminal-setup command also doesn't appear using kitty. I then tested in OSX terminal and /terminal-setup command does appear there - though I can't actually work out how to make it work

> /terminal-setup 
  ⎿  Enabled "Use Option as Meta key" for Terminal.app
  ⎿  Option+Enter will now enter a newline.
  ⎿  You must restart Terminal.app for changes to take effect.

I then restart terminal, and neither shift-enter nor option-enter seem to create a newline.

I then tried iTerm2, and ran /terminal-setup, and it did setup shift-enter and that does work for me.

To be honest, I don't really want to start using iTerm2, I'll probably just copy/paste from my editor into Kitty.

But maybe you could support shift-enter for Kitty in the future too?

FWIW, there is a Keyboard Protocol mentioned on the Kitty page, that says it can detect shift-enter, not just in kitty, other terminals (iTerm2, alacritty) support it too. I don't know much about this stuff, but just thought I'd share.

I beg anthropic to reconsider this. I've submitted so many prompts mid-prompt only for it to change code rapidly before I can cancel it.

I'm sure it can be done in a backwards compatible way without much pain, y'all are smart.

The benefit is huge for coding. I get the most value from big prompts that span multiple paragraphs.

Additionally and as such, I'm also frequently getting the most value out of prompts by typing out interfaces and code directly into the prompt manually to indicate how I want some API to look and it's very painful when it submits the code right away in the middle of a very large prompt.

I don't see an easier way to type code out and having to change muscle memory to remember the modifier for each newline is just bonkers considering it's adding thousands of new keypresses to the lifetime of the user relative to just one new modifier when submitting.

I'd much prefer type naturally using enter then submit using quite literally any modifier and enter (cmd, ctrl, opt, shift all work for me).

I'm curious why anthropic is against it?

I beg anthropic to reconsider this. I've submitted so many prompts mid-prompt only for it to change code rapidly before I can cancel it. I'm sure it can be done in a backwards compatible way without much pain, y'all are smart. The benefit is huge for coding. I get the most value from big prompts that span multiple paragraphs. Additionally and as such, I'm also frequently getting the most value out of prompts by typing out interfaces and code directly into the prompt manually to indicate how I want some API to look and it's very painful when it submits the code right away in the middle of a very large prompt. I don't see an easier way to type code out and having to change muscle memory to remember the modifier for each newline is just bonkers considering it's adding thousands of new keypresses to the lifetime of the user relative to just one new modifier when submitting. I'd much prefer type naturally using enter then submit using quite literally any modifier and enter (cmd, ctrl, opt, shift all work for me). I'm curious why anthropic is against it?

I don't speak for Anthropic. My personal reasoning is in that millions of people have "muscle memory" which is the reverse of your request - in IM apps from Skype to Slack Shift+Return is new line, Return is submit. On the command-line Return is submit, new lines are done by means of a backwards slash, e.g.

python -m epu_data_intake validate \
  ../smartem-decisions-test-datasets/bi37708-28-copy/Supervisor_20250130_145409_68practice2

What you are requesting is a "personal favour" contrary to how majority of users have been doing it for decades - and that's fine but it belongs under user-specific config IMHO.

Sure, I 100% understand the reasoning behind the default behavior, I wouldn't ever advocate for breaking existing peoples workflows.

However, I think it's completely reasonable for a CLI app to offer alternative ways to configure the box submission though. Don't you? Slack does, Gmail does, many apps do. Clearly it's not personal if other folks are asking too?

Agree this is very frustrating. I am trying to say paste some code from the clipboard and ask Claude Code to do something with it. Really awkward without SHIFT-ENTER making a newline. Also seems weird that I can paste newlines but not create them with the keyboard.

Edit: Ignore me. It's not a Claude thing it's the terminal setup. /terminal-setup sorted this when I moved to iTerm2

It is absolutely insane that your user interface for Claude Code uses a DIFFERENT newline than your web interface to Claude. This means I have to learn and use not one, but two different newlines depending on which interface to Claude I am using (I use both quite heavily, I just upgraded to Max and may need to upgrade again in the near future). I wouldn't expect you to change the default behavior for either, but you should make it configurable as this is actually wasting a lot of computer resources that you clearly can't spare. As for the argument that certain apps and areas of the internet have chosen to use Shift-Enter as the newline character, if that is the basis for the decision for either of these choices, you live extremely narrow lives, every touch-typist on the planet uses Enter as the newline for writing documents and programming. As someone who has been typing and programming since dinosaurs roamed the earth, it is really annoying. FWIW.

@vredchenko I don't think this argument passes the smell test, this seems more like an opinion than a fact, which is fine. People don't just use their terminals for commands, most of us have decades using vim, for example, and seeing -- INSERT -- while not actually being in insert mode (especially bad if your term doesn't support the terminal-setup command) is really bad UX.

BUT, not my product, just an opinion.

Tangentially related, but it would be great if Ctrl-X Ctrl-E opened $EDITOR, like in aider.

I know this was closed and not planned, but I wholeheartedly agree with the original post. Shift + enter does not work and I have to resort to copy / pasting in text from a text editor instead of typing it in the terminal because of this.

Edit: Shift + enter submits the prompt, it does not add a new line. \ is incredibly annoying to use on a nordic keyboard layout (Option + shift + 7).

While this is a known issue across various emulators, here's a workaround in VSCode IDE using keybindings.json (Ctrl+Shift+P > "Preferences: Open Keyboard Shortcuts (JSON)").

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

Note: space before \n is important for this to work.

Problem is possibly related to vscodes use of pseudo terminals (pty) rather than traditional tty environments. The /terminal-setup endpoint may not properly handle the complexities of pseudo terminal (pty) emulation, which differs from traditional tty environments in how it processes control sequences, line discipline, and input modes. Pseudo terminals introduce additional layers of abstraction that can interfere with raw keyboard input handling, its sound easy to fix but creating a universal solution across myriad of IDEs, terminal emulators, and their varying pty implementations makes this very complex.

Im getting the same issue that SHIFT + ENTER not working. Its sending everytime the command. I already tried /terminal-setup and it said:

/terminal-setup
⎿ Installed VSCode terminal Shift+Enter key binding
See /home/ismir/.config/Code/User/keybindings.json

Restarted VSCode and run claude again and inside the prompt window its again not working.

Why its not working? And what can i do to make it work?

@isi2010 confirmed, not working for me even after /terminal-setup + restart

macOS zsh

Try with below to narrow down on the root cause (vscode).

1354

My tested setup, no mod, working just fine -->

VSCode: 1.100.2
Windows 11 + WSL2 (Ubuntu)

Adding my voice to say its crazy that there is no config option for this. Web UI and terminal being different is diabolical work.

@adstr123 what web ui? for Claude Code(?) Claude Code and Claude.ai are different products

I don't mind that there is no config option, but for me it seems like neither shift+enter, nor \ works, so I'm not sure what is then the official key combination to add more lines? It looks to me that the CLI only accepts single line input.

I have read the whole thread and am confused about people saying shift-enter doesn't work in Claude Code because to the best of my knowledge Claude Code DOES NOT say anywhere they support it. At least on macOS.

Claude Code DOES say they support alt-enter (which is worse, and not aligned with Claude Web) but this requires "use option as meta key" to be ticked in the terminal. This is a bad solution because in international keyboards keys like \, #, @, {, } and others require option to be used.

Shift-enter would indeed be great, but alt-enter is particularly bad. Even ctrl-enter would be better than alt-enter (option-enter) . Particularly with # being an explicit keyword in Claude Code.

Thanks!

Indeed, alt+enter does the job.

@eduo heh so that makes the whole thing even more confusing. In macOS for instance, in the default Terminal app cmd+enter (I think?) is what works. On iTerm shift-enter works. In VSCode I think shift-enter works too. All of after issuing a the terminal setup command. And in the Claude frontend app (which people most likely use along CC, especially if they have Max), it's shift+enter.

Regardless, my original comment/complain was more about calling it a "vim mode" when it's actually not a vim mode at all.

It would be really nice if it were documented _somewhere_, other that in one of the last comments in this thread, that alt+enter is the correct key combination. In Gnome Terminal, shift+enter most definitely does not work. Claude Code command /terminal-setup does not appear to be real. Honestly, this aspect of the UI is kinda craptastic.

It's clear that changing the default behavior is not an option, so I created a new issue asking for the possibility to configure Claude Code (non default) so that ENTER inserts newline instead of submitting prompt: https://github.com/anthropics/claude-code/issues/2335

also notice
https://github.com/warpdotdev/Warp/issues/6401

@asgeo1 For Kitty, the following seems to work:

map shift+enter send_text all \\\n

For WezTerm:

config.keys = {
  {
    key = 'Enter',
    mods = 'SHIFT',
    action = wezterm.action.SendString '\\\n'
  }
}

Related: https://github.com/anthropics/claude-code/issues/1758

I ran into this after moving back to the gnome terminal after years of being shackled to vs code - and yeah if Shift-Enter doesnt do it, Alt-Enter will.

Basing any UI decisions based on what grey haired people have done is the past is a smell test in itself. - everything should be built with the young in mind, not the old.

And I am in my 50s. We had our time and our tech, I dont want it, I want the youth tech tyvm. Our tech sucked :D

Oh yeah, please make this configurable. I noticed alt+enter works but only via the vscode extension (haven't checked thoroughly, though). I did test on iterm2 (macOS Sequoia) and couldn't make any combo work. It's annoying because my muscle memory is trained to use shift+enter, but it ends up submitting the prompt :(

also on different machines and even different terminals, the hotkey is
different. it is maddening

On Thu, Jul 10, 2025 at 7:37 PM Marcelo Serpa @.***>
wrote:

fullofcaffeine left a comment (anthropics/claude-code#729) <https://github.com/anthropics/claude-code/issues/729#issuecomment-3060101545> Oh yeah, please make this configurable. I noticed alt+enter works but only via the vscode extension (haven't checked thoroughly, though). I did test on iterm2 (macOS Sequoia) and couldn't make any combo work. It's annoying because my muscle memory is trained to use shift+enter, but it ends up submitting the prompt :( — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/729#issuecomment-3060101545>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUJPNBGPO6RJL5MXIFQGHUT3H4PP7AVCNFSM6AAAAAB2SNAIA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRQGEYDCNJUGU> . You are receiving this because you commented.Message ID: @.***>

This tripped me up immediately. Had to hunt for it (and wound up here). Option+Enter on the default mac Terminal is entirely unexpected. How many times I've hit enter expecting a newline, and prematurely invoked a half-baked prompt instead...

Out of curiosity, why can't this be made configurable?

My ideal would be:

• Enter is a newline.
• Shift+enter fires it off.

Pretty much the assumed UI in nearly all other freeform text contexts.

how come this is still marked wiht not planned ?

how come this is still marked wiht not planned ?

@amoskueez I think because the OP asked to change the default behavior. I created a separate issue asking them to add a config option to override the default: #2335

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.