[FEATURE] Opt-in, state-independent submit key (Enter = newline; Mod+Enter = submit) — desktop + CLI; consolidates the Enter-to-send cluster

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Plain Enter submits immediately. For short phrases, pasted text, dictation (VTT), and IME/CJK composition (Enter confirms the candidate and fires a half-written prompt), this constantly sends incomplete messages. There is no setting to change it, and ~/.claude/keybindings.json is ignored in the desktop app (#25087). This is the most-duplicated input complaint in the tracker (full cluster in Additional Context), unresolved for a year despite 116+ 👍 on #2054.

Proposed Solution

An opt-in setting for the composer submit key. Default OFF = today's Enter-to-send (no existing user affected). When ON:

• Bare Enter never submits — in ANY input state (empty, one word, one line, pasted, dictated, multiline). Enter is ordinary text entry.
• Submit requires a command chord: Ctrl+Enter (Windows/Linux) / Cmd+Enter (macOS).
• 🔴 State-independent — must NOT gate on line count. A "multiline-only" version (Enter stops submitting only once the box is multi-line) is the wrong behavior and the current broken half-state (#25087, #34319, #25145).

Acceptance criteria:

• Setting OFF → behavior identical to today (Enter submits).
• Setting ON → Enter inserts a newline in every composer state: empty, one word, one line, multiline, pasted, dictated.
• Setting ON → Ctrl+Enter / Cmd+Enter submits.
• Behavior does not depend on whether the buffer already contains a newline.
• Honored in the desktop app, not only the CLI.

Alternative Solutions

• A multiline-scoped toggle (submit-on-Enter only once the box is multi-line) — rejected: it's an invisible mode switch, fails for single-line / pasted / dictated / IME input, and is the current half-broken behavior.
• ~/.claude/keybindings.json (enter → chat:newline) — ignored in the desktop app (#25087), and the CLI single-line path still submits (#34319).

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Example scenario:

1. I dictate a multi-sentence prompt by voice. The speech-to-text engine inserts newlines unpredictably, so with Enter = send the prompt fires mid-thought.
2. I type a short phrase and press Enter intending to add a second line — instead it sends the half-written message.
3. A Japanese IME user presses Enter to confirm kanji conversion — it submits the incomplete prompt.

In each case bare Enter should have inserted a newline, and submission should have required an explicit Ctrl+Enter / Cmd+Enter.

Additional Context

Why this is not a duplicate: it consolidates the ~25 existing "Enter-to-send" issues into one design and adds two things none of them carry — the precise state-independent invariant (above) and an implementation-ready spec from a competitor that already ships it.

Prior art — OpenAI Codex:

• Publicly documented (CLI/TUI): configurable composer bindings in ~/.codex/config.toml:

``toml
[tui.keymap.composer]
submit = ["enter", "ctrl-m"]
`
Keymap entries are customizable and an empty list unbinds an action, so submit can be moved off the bare-Enter key path (remove every sequence that represents bare Enter — enter and, where applicable, ctrl-m`, historically carriage return). Docs: https://developers.openai.com/codex/config-basic

• Publicly documented (Desktop GUI): Codex App › General has a "require Cmd+Enter for multiline prompts" option, plus Settings › Keyboard Shortcuts (that option is multiline-scoped — the weaker behavior). Docs: https://developers.openai.com/codex/app/settings , https://developers.openai.com/codex/app/commands
• Observed in the shipping Codex Desktop app (not yet in OpenAI's public TOML reference): the installed app accepts [desktop] composerEnterBehavior = "cmdAlways" — plain Enter always inserts a newline, Mod+Enter submits, all states; the enum family also includes cmdIfMultiline (the weaker mode). Cited as observed shipping-app behavior, not public config docs.

Zero risk: opt-in, default unchanged — no workflow changes unless chosen; a peer product already ships both the weak and the strong modes, so the design is settled.

Consolidated duplicates:

• Same request: #2054 (116+ 👍), #2335, #6678, #10635, #12548, #5064, #6533, #7646, #20558, #26303, #54433 (closed invalid), #33034 (desktop; closed "not planned")
• IME / CJK accidental-send: #1306, #7612, #8405
• Shift+Enter / newline broken: #6535, #7958, #9321, #15357, #25057, #25145, #27465, #34319
• Desktop-specific: #25087, #33034, #25145