Synced from GitHub
fix(web): honor the send shortcut for follow-up actions#20929
Problem
Choosing Cmd/Ctrl+Enter always as the send shortcut makes follow-ups use the opposite of the configured Follow-up behavior. For example, select Steer, start a turn, type a follow-up, and press Cmd+Enter: the message queues instead of steering. Selecting Queue produces the reverse problem. The multiline-only send option has the same conflict when the prompt contains a newline.
The alternate-action binding claims Cmd/Ctrl+Enter before the composer applies the send preference. The key required for an ordinary send is therefore also treated as an explicit override.
This regresses behavior introduced in #12075. The diff for #12174 removed the check that distinguished a required send modifier from an alternate-action modifier when it moved submission to configurable keybindings. It also replaced the preference-aware follow-up tests with tests expecting Mod+Enter to select the alternate action for every send mode. This PR restores that distinction while retaining configurable shortcuts.
Change
Resolve the default alternate-action chord against the current send preference. When sending requires Cmd/Ctrl+Enter, that chord uses the configured follow-up action and Cmd/Ctrl+Shift+Enter uses its opposite. When Enter sends, the existing mapping remains.
Shortcut matching and displayed hints share this resolution, including the chat's global shortcut handler. It works with the Mod+Enter binding already saved by existing installs, without rewriting their keybindings file. Other remapped chords remain available. While the composer is focused, the alternate draft action takes precedence over steering the oldest queued message; outside the composer, the queued-message shortcut remains available. The composer guide explains this distinction.
Web and desktop share the fix. Native mobile already implements the preference-aware chords. New-thread background sends and provider/server dispatch are unchanged.
Scope and approval
This is a focused correction to an existing setting: restore the behavior described by Settings and originally shipped in #12075. It adds no setting or workflow.
Related work found by searching open and closed issues/PRs:
- #19773 (open) reports a related documentation mismatch; #19929 was a documentation-only PR closed without merging. This PR does not claim to resolve that separate report.
- #14429 (closed) reports the related modifier-required send conflict for new threads. The maintainer triage explains why a modifier required to send must not automatically select a secondary action, and notes the Shift-modified follow-up override. That report and #14443 concern foreground/background behavior; #15060 subsequently restored the background shortcut, which this PR preserves.
- #1462 (closed, consolidated into #231) explicitly requested consistent follow-up behavior across keyboard and button submissions, with a one-message override. These are references for the intended interaction, not reports of this later regression.
Searches of open and closed issues did not find a report of this exact follow-up shortcut regression. The issue links above are related context, not closing references. No open PR fixing the exact interaction was found before this PR was opened.
Verification
From apps/web:
sh
| 1 | pnpm exec vp test run --project unit --maxWorkers=1 --no-file-parallelism src/composer-logic.test.ts src/keybindings.test.ts src/components/settings/KeybindingsSettings.logic.test.ts |
269 tests passed across 3 files. Coverage includes both follow-up defaults, all send modes, single-line/multiline prompts, macOS/Windows/Linux modifiers, saved bindings, remapped shortcuts, displayed shortcut labels, and queued-message shortcut precedence. The run used one CPU at low CPU/I/O priority.
The commit's formatting hook and git diff --check passed. Targeted lint could not complete: its allocator panicked even with --threads=1. Typechecking and native desktop/macOS interaction verification remain incomplete.
Browser interaction evidence
Verified in Chromium on Linux through T3 Code's Browser panel against an isolated dev instance and disposable project, using a live Codex run waiting on sleep. Linux uses Ctrl for the same Mod shortcut that uses Command on macOS.
- Before (
89b42bfeb4): with Ctrl+Enter always and Steer selected, Ctrl+Enter incorrectly places the follow-up in Queued. - After (
8aec848b3c): the same preferences and Ctrl+Enter produce a Steer message; Ctrl+Shift+Enter queues instead. - Also checked Queue as the default: Ctrl+Enter queues and Ctrl+Shift+Enter steers.
- Also checked multiline mode with a multiline prompt and Steer selected: Ctrl+Enter steers and Ctrl+Shift+Enter queues.
The captures are unmodified browser screenshots. Evidence files are hosted in a clearly labelled review-evidence prerelease in the contributor fork; no media files were committed.
Selected preferences
| Before: Ctrl+Enter incorrectly queues | After: Ctrl+Enter steers |
|---|---|
| Before: follow-up appears in Queued | After: follow-up appears as Steer |
Short recording: Ctrl+Enter steers after the fix · Screenshot: Ctrl+Shift+Enter queues
Model: GPT-6-Astra. Harness: Codex in T3 Code.
Checks
24 successful · 10 skipped
Added 1 commit
- fix(web): honor the send shortcut for follow-up actions8aec848
Synced from GitHub
Approvability
Verdict: Approved at 8aec848
Macroscope's review found this PR approvable — This is a contained bug fix that makes follow-up shortcuts honor the existing send preference while preserving defaults, remapped shortcuts, and non-composer behavior. Production changes are localized and accompanied by targeted coverage and documentation updates.
You can add or adjust custom eligibility rules. Learn more.
Synced from GitHub
No actionable comments were generated in the recent review. 🎉
ℹ️ Recent review info
⚙️ Run configuration
- Configuration used: Path: .coderabbit.config.ts
- Review profile: CHILL
- Plan: Advanced
- Run ID:
08f60338-0bdc-40c8-a735-4a438084f2a8
📥 Commits
Reviewing files that changed from the base of the PR and between 133f57a8321767d51610c50a16edb8b7181ededf and 8aec848b3c3044ba1831798f44cc46e69523375e.
📒 Files selected for processing: 7
apps/web/src/components/ChatView.tsxapps/web/src/components/chat/ChatComposer.tsxapps/web/src/composer-logic.test.tsapps/web/src/composer-logic.tsapps/web/src/keybindings.test.tsapps/web/src/keybindings.tsdocs/user/composer.md
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
📝 Walkthrough
Composer shortcut context now includes whether the configured send shortcut requires a modifier. Alternate-send shortcut resolution, effective shortcut reporting, and event matching use that context. Tests cover platform and prompt variations, and the composer documentation describes the shortcut behavior.
Changes: Composer shortcut resolution
Layer / File(s) Summary Provide composer modifier context
apps/web/src/composer-logic.ts,apps/web/src/components/ChatView.tsx,apps/web/src/components/chat/ChatComposer.tsxcomposerRequiresModifieris exported and passed into shortcut resolution and shortcut-label context using the configured send shortcut and current prompt.Resolve context-adjusted shortcuts
apps/web/src/keybindings.tsAlternate-send bindings for unmodified Mod+EntergainShiftwhen the composer context requires a modifier. Effective shortcuts, conflict keys, and event matching use the adjusted shortcut.Verify shortcut behavior and document it
apps/web/src/composer-logic.test.ts,apps/web/src/keybindings.test.ts,docs/user/composer.mdTests cover send preferences, prompt length, platform modifiers, remapped keys, and composer focus. Documentation describes the alternate action and queued-message steering behavior. Priority: ⬇️ Low
Estimated code review effort: 3 (Moderate) | ~20 minutes
Change: Bug fix
Sequence Diagram(s)
mermaid1 sequenceDiagram 2 participant KeyboardEvent 3 participant resolveShortcutCommand 4 participant shortcutForContext 5 KeyboardEvent->>resolveShortcutCommand: provide event and shortcut context 6 resolveShortcutCommand->>shortcutForContext: resolve configured binding 7 shortcutForContext-->>resolveShortcutCommand: return context-adjusted shortcut 8 resolveShortcutCommand-->>KeyboardEvent: return matching command Suggested reviewers:
juliusmarminge
Merge Risk: ⚪ Minimal · up to 8aec8
The change makes the follow-up shortcut honor the configured send shortcut, and no actionable merge-blocking issue was found.
Pre-merge checks: Passed 4
Check name Status Explanation Linked Issues check Passed Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request. Description check Passed The description includes all required sections. It clearly states the problem, explains the implementation, defines the focused scope, and documents targeted tests, observed results, limitations, and … Title check Passed The title is concise, specific, and accurately describes the main change: follow-up actions now honor the configured send shortcut. Full details: Description check
Explanation
The description includes all required sections. It clearly states the problem, explains the implementation, defines the focused scope, and documents targeted tests, observed results, limitations, and browser evidence.
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create a new PR
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.