[Feature Request] Configurable composer send shortcut: Ctrl/Cmd+Enter to send, Enter inserts a newline

[chenchanghong12]

The problem

The composer currently binds the bare Enter to send and Shift+Enter to a line break, with no way to change it. For users writing long, multi-line prompts (which is the norm when orchestrating agents), Enter-as-send is a footgun: one accidental keystroke submits a half-written instruction. Most chat/agent front-ends (Slack, Discord, VS Code Copilot Chat, ChatGPT, Claude) offer a "Ctrl+Enter sends, Enter breaks line" mode for exactly this reason.

Proposed design

A durable preference in the existing ui-conversation settings namespace:

• Field: sendShortcut: 'enter' | 'ctrlEnter' (default 'enter' — current behavior; the schema default keeps old documents valid)
• 'enter' (default): unchanged — Enter sends, Shift+Enter breaks the line
• 'ctrlEnter': the bare Enter falls through to the editor's native line break; only the Ctrl/Cmd chord reaches the submit gesture. The chord keeps the existing "accelerated gesture" semantics (the opposite of the busy-Enter preference while an agent is running)
• Settings UI: one new row in Settings → General, right below the existing busy-Enter row ("Send shortcut: Enter sends / Ctrl+Enter sends (Enter breaks line)"), zh + en locale strings included

Why this can't live in an external plugin

The Enter decision happens inside the composer keymap (packages/client/ui-conversation/src/client/input/editor/keymap.ts) at COMMAND_PRIORITY_CRITICAL, before any extension point. An external plugin can neither intercept that decision nor substitute the composer bar without forking the whole skeleton, so the change has to be core.

Implementation

A complete, tested patch is attached (send-shortcut.patch — 17 files, +196/−22), following the existing busy-Enter preference architecture end to end:

• submission-settings.ts: field, vocabulary, schema default (old documents stay valid)
• submission-policy.ts: reactive store, setSendShortcut, host adoption without write-back
• keymap.ts: one optional handler (sendOnCtrlEnter) — absent means Enter-sends, so every existing embedding keeps working
• InputBar.tsx: wires the live preference through the existing gate ref (no re-arm per keystroke)
• SendShortcutRow.tsx: the Settings row (mirrors EnterBehaviorRow's shape and styling, reuses its module CSS)
• contract/slots/locales/exports updated

Verification:

• tsc -b tsconfig.client.json — clean
• All 430 tests in 102 suites of packages/client/ui-conversation pass, including:
  • keymap-routing: synthetic keydowns — in ctrlEnter mode the bare Enter is not consumed and never submits; Ctrl and Cmd chords both submit; Shift+Enter stays a native break in both modes
  • input-bar (component bench): rendered composer — bare Enter does not submit while the chord does (with busy-state gesture semantics); flipping the preference live flips the bare-Enter behavior
  • submission-policy: defaults, scope write-through, host adoption
  • host: schema registration, defaults, invalid-value rejection, dispose
  • apply-wiring / input-matrix / input-scenarios / skeleton: props-contract adapters updated for the new hook

Alternatives considered

• Doing nothing: Shift+Enter already covers line breaks, but it doesn't help the accident case — Enter is the muscle-memory key for "newline" in every text editor, and an accidental submit of a half-written multi-line prompt is disruptive (queued into a running agent or sent mid-thought).
• A browser-side keyboard shim plugin: rejected — it would fight the editor's own keymap and break with IME composition handling (the keymap's composition guards exist precisely because of that).

Happy to rework any part of this to match the team's preferred shape if the feature is accepted — e.g. a different field name, a third mode, or folding the row into the existing busy-Enter row.
send-shortcut.patch