[BUG] chat:newline keybinding submits message when input has text
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Remapping enter to chat:newline in ~/.claude/keybindings.json does not fully work when the input contains text.
## Keybindings config
```json
{
"context": "Chat",
"bindings": {
"shift+enter": "chat:submit",
"enter": "chat:newline"
}
}
What Should Happen?
Pressing Enter always inserts a newline, regardless of whether the input is empty or contains text.
Error Messages/Logs
Steps to Reproduce
## Keybindings config
{
"context": "Chat",
"bindings": {
"shift+enter": "chat:submit",
"enter": "chat:newline"
}
}
Expected behavior
Pressing Enter always inserts a newline, regardless of whether the input is empty or contains text.
Actual behavior
- Empty input: Enter correctly inserts a newline.
- Input with text: Enter submits the message AND leaves a duplicate copy of the text in the input field (as if attempting both
newline and submit simultaneously).
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.49
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
VS Code integrated terminal
Additional Information
Environment
- macOS (Darwin 24.6.0)
- Tested in both VS Code integrated terminal and iTerm2 — same behavior in both
- Claude Code CLI (latest)
Notes
- Option+Enter (default macOS multiline shortcut) works correctly in all cases
- The keybinding is being recognized (the duplicate text left in the input suggests partial newline behavior), but submit is not
fully suppressed
Showing cached comments. Read the full discussion on GitHub ↗
12 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Don't know why that issue got closed, but this is a bug that "enter": "chat:newline" does not work
I have the same issue with remapping keys
newline and submit simultaneously)
same bug here on claude 2.1.71 (macos + iterm2)
same on regular macos terminal. this has been broken for weeks.
i had created a keybindings file trying to get it to work when it was first announced, but it never did anything.
now, as of 2.1.72, it makes enter (which still submits anyway) also fail to clear the prompt, so the UI becomes
basically unusable until the entire mess is reverted to the default. the "feature" still isn't documented,
so maybe they think no one will notice if it doesn't work ...
Still an issue for me - Windows 11 Home / wezterm 20260117-154428-05343b38
I'm experiencing the same issue. Enter submits the message even when it's remapped to chat:newline in keybindings.json.
Same issue here, but even broader — no keybinding works for
chat:newlineat all.Tested keybindings.json configs:
"alt+enter": "chat:newline"— does not insert newline"option+enter": "chat:newline"— does not insert newline"ctrl+enter": "chat:newline"— does not insert newlineAll three submit the message instead of inserting a newline.
Environment:
Note: the original report mentions "Option+Enter works correctly as the default macOS multiline shortcut" — that is not the case on my setup either. Option+Enter also submits the message.
Confirm this issue still broken. Why are they closing all the issues and not fxing it?
Platform: macOS (terminal, not IDE extension)
Version: 2.1.123
Adding another reproduction case. My desired keybinding setup is Enter = newline, Cmd+Enter = submit (the standard pattern in most chat UIs).
keybindings.json:
Expected: Enter inserts a newline, Cmd+Enter submits.
Actual: Enter correctly inserts a newline, but Cmd+Enter does nothing. The Enter binding appears to be greedy — it captures the keypress regardless of modifiers, so the
meta+enterbinding never fires. There's no way to submit.This makes the Enter/Cmd+Enter pattern unusable. The same issue occurs with Shift+Enter as the submit binding.
Something worth noting: Shift-Enter doesn't come through many terminals, and it looks like Enter by default. But that is not the problem.
By using cat -v and configuring the terminal you can work avoid this issue. My current configuration is below. Using this I find that Shift+Enter gives me a new line inside a message and Enter submits it (the opposite of what I want, and trying to configure Claude Code the other way around doesn't have any effect on what key submits a message)
My current .claude/keybindings.json:
The relevant part of my .wezterm.lua:
still not behave as expect in this issue body as of 2.1.139