Focused rich-text composer overrides configurable app keybindings with hardcoded formatting shortcuts #34336

What happened

Configurable app keybindings can stop working while the rich-text chat composer is focused if their chord collides with a hardcoded editor formatting shortcut.

Verified example on T3 Code Desktop 0.1.9: bind Show Usage (usage.open) to Mod+E or Mod+I. Either binding works outside the composer but does nothing while the composer is focused. The editor consumes the chord for inline-code or italic formatting before the configured app command receives it.

This is not specific to Show Usage. usage.open is the deterministic reproduction. Commands with special capture-phase handlers can behave differently; for example, the default Mod+B sidebar binding still works because sidebar.toggle has explicit conflict handling.

Diagnosis

This is a client-side shortcut precedence defect.

In v0.1.9 (24e77473ecf41bc1f7142529c7911c1c1aae1d76), the rich-text composer inherits Tiptap formatting shortcuts. ComposerMarkdownSourceExtension also hardcodes Mod+B, Mod+I, Mod+Shift+S, and Mod+E outside the configurable keybinding system.

Normal app commands such as usage.open are registered in a non-capture global command scope. The shared dispatcher runs those scopes from a bubbling window listener. A focused Tiptap editor can handle and prevent a colliding key event first, so the configured app command is never reached.

sidebar.toggle on Mod+B is an exception because the codebase gives it a dedicated capture-phase listener plus special rich-text selection handling. That special case explains why the default sidebar shortcut works but does not solve the general collision for other configurable commands or editor-owned chords.

The same hardcoded formatting shortcuts and bubbling global command path remain on main at 5da53f87d9feba9717bca516215aa3dedd0a694a, so no released update currently fixes this.

Steps to reproduce

1. Open T3 Code Desktop.
2. Open Settings → Keybindings.
3. Set Show Usage (usage.open) to Mod+E.
4. Return to a chat and focus the rich-text composer.
5. Press Mod+E.
6. Observe that Usage does not open.
7. Move focus outside the composer and press Mod+E.
8. Observe that Usage opens.
9. Repeat with usage.open bound to Mod+I; the same focus-dependent failure occurs.

Expected: the configured app keybinding takes precedence, or the conflict is surfaced and rejected.
Actual: the focused editor silently consumes the configured chord.

Version

0.1.9

Environment

macOS arm64 27.2.0; T3 Code Desktop 0.1.9 connected to local server 0.1.9; Node 26.12.1; triage CLI 0.1.9.

Evidence

v0.1.9 commit:
24e77473ecf41bc1f7142529c7911c1c1aae1d76

apps/web/src/composer-markdown-source.ts:561-566
"Mod-b": toggle("bold")
"Mod-B": toggle("bold")
"Mod-i": toggle("italic")
"Mod-I": toggle("italic")
"Mod-Shift-s": toggle("strike")
"Mod-e": toggle("code")

apps/web/src/shortcuts/dispatcher.ts:82-83
window.addEventListener("keydown", dispatchCaptureKeyDown, true)
window.addEventListener("keydown", dispatchKeyDown)

usage.open is registered in the non-capture global command scope.
sidebar.toggle has separate capture-phase conflict handling.
No server error is expected because the event is consumed entirely in the client.

Related issues

#34136 — related report about app shortcuts being blocked by terminal focus, but not a duplicate: this report concerns focused rich-text editor shortcuts overriding configured app keybindings.

Fix applied or workaround

No fix was applied. Rebinding affected commands to chords not claimed by the rich-text editor, such as Mod+Alt+E, avoids the collision.

Filed by

Codex (GPT-5) via t3 triage