[FEATURE]: Setting to send prompt only with send button, not hitting enter. #16226

Activity

1. ronixinc

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Mar 5, 2026
2. github-actions

   assigned

   thdxr

   on Mar 5, 2026
3. github-actions commented on Mar 5, 2026

   

   github-actionsBot

   on Mar 5, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Allow to Shift + enter to edit in next line without enter #9836: Feature request to allow Shift+Enter to insert a new line instead of sending (same core problem - difficulty composing multi-line prompts)
   • Keybinds #4997: Pinned keybinds documentation that may cover related configuration options

   For keybind-related issues, please also check our pinned keybinds documentation: #4997
4. alexyaroshuk commented on Mar 5, 2026

   

   alexyaroshuk

   on Mar 5, 2026

   Contributor

   More actions

   Would this addresses the issue ?#13637
5. ronixinc commented on Mar 6, 2026

   

   ronixinc

   on Mar 6, 2026

   Last edited by ronixinc

   Author

   More actions

   Thanks for your answer. I believe it partly does, and I'll probably use the setting if merged. I think having a little label above the send button that reads "Enter = sends message"/"Enter = new line" could add to the UX.

   I think the issue needs a bit more discussion though, but I wouldn't delay your merge for it.

   Prompts (specially for engineers) are becoming complex text. I haven't seen any LLM's chat interfase address this. I wonder why the simple "text blob" hasn't still evolved to a UI that would allow text enrichment. I don't mean more than what we have here in github: simple formatting, bullets, hyperlinks, code, etc. Enter means a new line, since I'm not chatting: I'm building an argument, reasoning, showing something. Then I submit by clicking a button outside the text box. Or maybe ctrl+enter, as you suggest.

   Anyways, I believe it's worth thinking about it. (I could close this issue and open a different one for this discussion.)
6. alexyaroshuk commented on Mar 7, 2026

   

   alexyaroshuk

   on Mar 7, 2026

   Contributor

   More actions

   Thanks for your answer. I believe it partly does, and I'll probably use the setting if merged. I think having a little label above the send button that reads "Enter = sends message"/"Enter = new line" could add to the UX.

   I think the issue needs a bit more discussion though, but I wouldn't delay your merge for it.

   Prompts (specially for engineers) are becoming complex text. I haven't seen any LLM's chat interfase address this. I wonder why the simple "text blob" hasn't still evolved to a UI that would allow text enrichment. I don't mean more than what we have here in github: simple formatting, bullets, hyperlinks, code, etc. Enter means a new line, since I'm not chatting: I'm building an argument, reasoning, showing something. Then I submit by clicking a button outside the text box. Or maybe ctrl+enter, as you suggest.

   Anyways, I believe it's worth thinking about it. (I could close this issue and open a different one for this discussion.)

   i see what you saying, however bear in mind that the agent receives plain text. Your formatting does not really matter when it comes to reasoning. And, you can always create a doc file and mention it in the prompt, i.e. 'refer to this spec spec.md', and in that doc you can format however you like
7. alexchandel commented on Mar 13, 2026

   

   alexchandel

   on Mar 13, 2026

   More actions

   Mobile users need a setting like or equivalent to this for the web (and probably by implication desktop) UI. It's currently impossible to type a newline on mobile via the normal keyboard.
8. CasualDeveloper commented on Apr 19, 2026

   

   CasualDeveloper

   on Apr 19, 2026

   Last edited by CasualDeveloper

   Contributor

   More actions

   Proposed fix in #23430. Approach:

   Register prompt.submit (default enter) and prompt.newline (default shift+enter) as web commands so they surface in the existing Settings → Keyboard Shortcuts UI (auto-groups under "Prompt" via the id prefix). Dispatch stays local in prompt-input.tsx's handleKeyDown via matchKeybind. No new config schema; no migration; defaults preserve current behavior byte-for-byte.

   Manual browser walkthrough completed — all four combinations (default/swapped × submit/newline) verified via Chrome DevTools against the built desktop instance. Zero accidental submissions thanks to event.stopPropagation() + the existing empty-content guard in handleSubmit.

   (First attempt #23378 was auto-closed by the compliance bot before I'd run the manual walkthrough; #23430 supersedes it.)

   Happy to adapt approach or drop if not wanted.
9. 45 remaining items

   Load more
10. github-actions commented on Aug 6, 2026

    

    github-actionsBot

    on Aug 6, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
11. github-actions

    closed this as not plannedon Aug 6, 2026
12. CasualDeveloper commented on Aug 9, 2026

    

    CasualDeveloper

    on Aug 9, 2026

    Last edited by CasualDeveloper

    Contributor

    More actions

    This is still relevant. The issue was closed by inactivity cleanup rather than because the behavior was resolved.

    Although the closed PR view is frozen at an older commit, the source branch for my PR #23430 is actively maintained and was recently refreshed against dev. It exposes prompt.submit and prompt.newline through the existing Keyboard Shortcuts settings, keeps Enter/Shift+Enter defaults unchanged, and supports both current prompt composers while keeping dispatch editor-local.