René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Keyboard shortcut to open the composer's thinking (reasoning effort) menu (⌘⇧E)","articleBody":"## Problem or Motivation\n\nOpenWork's composer toolbar has three picker controls — the **model picker**, the\n**thinking-level (reasoning effort) picker** (added in #45), and the\n**permission-mode selector**. Two of those already have keyboard access: the\npermission mode cycles with `Shift+Tab` (`chat.cyclePermissionMode`). But the\n**thinking-level menu can only be opened with the mouse** — there is no keyboard\nshortcut to open it.\n\nClaude Code Desktop documents a dedicated **effort menu shortcut (`⌘⇧E`)** in its\ncomposer, right next to the model menu (`⌘⇧I`) and permission-mode menu (`⌘⇧M`).\nWhen the thinking-level picker itself landed here (#44), the issue explicitly\nflagged this as a natural follow-up:\n\n\u003e A keyboard-only shortcut (à la `⌘⇧E`) could open a menu … A shortcut can be\n\u003e layered on later.\n\nThis issue layers it on: press `⌘⇧E` (macOS) / `Ctrl+Shift+E` (Windows/Linux) to\nopen the composer's thinking-effort menu from anywhere, without reaching for the\nmouse — matching Claude Code Desktop's effort-menu shortcut exactly.\n\n## Proposed Solution\n\nAdd a `chat.openThinkingMenu` action (default hotkey `mod+shift+e`, category\n**Chat**) to the renderer action registry. When triggered it opens the composer's\nexisting thinking-level dropdown (`FreeFormInput`'s already-controlled\n`thinkingDropdownOpen` state).\n\nBecause the action registry lives at the app shell while the dropdown's open\nstate lives inside the composer, the shortcut is bridged with a small scoped\ncustom event (`craft:open-composer-menu`), mirroring the existing\n`craft:focus-input` pattern (`shouldHandleScopedInputEvent`) so that in\nmulti-panel layouts only the **focused** panel's composer responds.\n\nThis is a **frontend-only** change:\n\n- No backend / qwen-code change. It reuses the composer's existing controlled\n  dropdown state and the existing action-registry + hotkey infrastructure.\n- Because it registers in the action registry, the shortcut **automatically**\n  appears in the Command Palette (#42) and the Keyboard Shortcuts reference —\n  no extra wiring.\n- One new i18n key (`shortcuts.action.openThinkingMenu`) added to all locales\n  for the action label; the shortcut itself has no new visible chrome.\n\n## Alternatives Considered\n\n- **Model menu (`⌘⇧I`) / permission-mode menu (`⌘⇧M`) shortcuts too:** Claude\n  binds all three. `⌘⇧I` / `Ctrl+Shift+I` is already reserved for **Developer\n  Tools** in OpenWork's menus, so reusing it would conflict; and permission mode\n  already has a keyboard affordance (`Shift+Tab`). The thinking menu is the one\n  composer picker with *no* keyboard access and *no* binding conflict, so this\n  scopes to `⌘⇧E` — the cleanest, conflict-free gap.\n- **A visible extra affordance:** unnecessary; the value here is precisely the\n  no-mouse path to the existing picker.\n\n## Additional Context\n\nFeasibility: **frontend-only / doable.** Verified against `apps/electron` — the\nthinking dropdown already owns a controlled `thinkingDropdownOpen` state and\ncarries `data-testid=\"thinking-level-trigger\"` / `thinking-level-item` hooks\n(from #45), so opening it programmatically needs no structural change.\n\n### Acceptance criteria (CDP e2e assertion)\n\nA new `e2e/assertions/thinking-menu-shortcut.assert.ts` drives the real built app\nover CDP entirely in the draft (no-session) state — no seeded conversation and no\nbackend:\n\n1. The composer renders the thinking-level trigger with its menu **closed** (zero\n   visible menu items).\n2. Dispatch the `Cmd/Ctrl+Shift+E` keydown at the window level (where the action\n   registry's capture-phase listener lives).\n3. The thinking menu **opens** and lists all **six** levels.\n\nAsserting the menu is closed *before* the keypress and open *after* it proves the\nshortcut actually opens the menu, not merely that the menu can render.\n\nPart of the autonomous desktop-feature loop (`loop-bot`).","author":{"url":"https://github.com/DragonnZhang","@type":"Person","name":"DragonnZhang"},"datePublished":"2026-07-04T13:38:55.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/54/openwork/issues/54"}