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

[ronixinc]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Prompts are getting more complex and multi-paragraph. I don't know if I'm the only one frustratred when hitting enter to continue writing but instead have the prompt sent by mistake. Using shift+enter is a bit unnatural, even though is the usual in other apps too. I believe it could be customized to only have the prompt sent by clicking the send button.

Alternative: have pop up button that opens a text box in a modal so you can build the prompt properly, save it and then send it.

Final thought: I believe writing a prompt deserves something a little more complex than a regular chat bubble and send-by-enter.

Thanks for reading! (I've searched and didn't find this issue. Apollogies if I missed it)

[github-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

[alexyaroshuk]

Would this addresses the issue ?#13637

[ronixinc]

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.)

[alexyaroshuk]

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

[alexchandel]

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.

[CasualDeveloper]

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.