Sign up
View stargazersSign up

[Bug]: Send shortcut (Cmd+Enter) when activated in settings, sends the new threads as background threads.#14429

openedSep 30, 2026byBbelizariogr

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Go to settings, General, on "Send shortcut", set it to "Cmd+Enter always";
  2. Go back to main screen and start a new thread.
  3. Type anything (including multi-line text)
  4. Hit: "Cmd+Enter".

Expected behavior

Just send the prompt and start running normally.

Actual behavior

The thread will begin to run in the background.

When the send shortcut is set to "Enter" only, this is the correct behavior... but its conflicts with the new options (please dont remove it).

After first send, the hotkey works correctly.

Impact

Minor bug or occasional failure

Version or commit

0.0.45-nightly.20260930.2481 (c18e5ea6ed74)

Environment

macOS 27

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

2026-09-30 10-11-01.mov

Workaround

No response

JJulius MarmingeSep 30, 2026

Triage

Confirmed. With Send shortcut set to ⌘ + Enter always, pressing ⌘+Enter on a new thread starts it in the background instead of sending normally. With the Enter setting, ⌘+Enter on a new thread still starts it in the background, and that should stay.

composerSubmissionIntentForEnter in apps/web/src/composer-logic.ts already treats ⌘/Ctrl+Enter as the send key when sendShortcut is mod-enter (and when it's mod-enter-multiline and the draft has a newline). But the last line ignores that and still returns "background" whenever the modifier is held on a draft:

apps/web/src/composer-logic.ts (line 44):

ts
1 return input.modifierKey && input.isDraftThread ? "background" : "foreground";

That's what opens a fresh draft and shows the "Started in background" toast. After the first message the thread is no longer a draft, so the same shortcut sends normally, which matches what you saw in the video.

In this mode there's currently no keyboard shortcut for a normal first send. Enter adds a newline, and so does ⌘+Shift+Enter. The Send button still works as expected. The same problem shows up with ⌘ + Enter for multiline prompts once the draft has a newline in it. A single-line draft in that mode is fine, because Enter sends and ⌘+Enter can keep meaning background.

This has been the behavior since the send-shortcut setting landed, and the line is unchanged on current main. The keybindings doc also still says mod+Enter always starts a new thread in the background, which is only true when Enter itself sends.

The fix is to return "background" only when the modifier isn't needed to send, and to add tests for mod-enter and multiline mod-enter-multiline on a draft. Background start would then need a different shortcut in those modes. ⌘+Shift+Enter is free on a draft, since it's only used as the follow-up override while a turn is running.

Thanks for the clear repro and the recording.

JJulius Marminge29d ago

Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

Current composer gives background send an explicit mod+alt+enter binding. Modifier-required Enter submits in the foreground when no special binding matches, removing the original draft-only mod+Enter background fallback.

I’m closing this based on the current source and the evidence in this thread.

Source reviewed.

Custom user keybindings can intentionally choose different behavior. Source assessment, no keyboard UI test.

If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.