[Feature] Separate the command palette (⌘K) from session search (⌘⇧F), per the VS Code convention

[randypitcherii]

Problem or use case

The global command palette (⌘K, added in #1385) is currently doing two unrelated jobs at once. It opens with a Sessions group listed first — a debounced server search over session titles and chat content — and an Actions group of static app commands below it. The input placeholder says it out loud: Search sessions or run a command.

Two consequences today:

1. The two tasks fight each other. Finding a session and running a command have different rhythms — one is a fuzzy content search over potentially hundreds of rows, the other is a short pick from a fixed list. Because the session results render first and, once you type, uncap themselves (IDLE_SESSION_LIMIT only applies to the idle list), typing anything that also matches a session title pushes the Actions you were reaching for below the fold. CommandPalette.tsx already carries a workaround for this — the idle cap exists purely "so both groups fit without scrolling".
2. There is no way to search sessions without going through the command palette. The sidebar's inline "Search sessions" input was removed when the palette shipped; Sidebar.tsx now reads // Session search now lives in the command palette and the sidebar's magnifier button just calls onOpenSearch?.() → setCommandPaletteOpen(true). So the sidebar's search affordance opens a surface whose first-class content is app commands.

VS Code — the convention this UI is clearly reaching for — keeps these on separate keys precisely because they are separate tasks:

VS Code	Key	Omnigent analogue
Command Palette (commands only)	⌘⇧P	the Actions group
Quick Open (jump to a file)	⌘P	jump to a session
Search across file contents	⌘⇧F	session search, incl. chat-content matches

Omnigent's session search is closer to VS Code's ⌘⇧F than to ⌘P: it is a server-side full-text search over conversation content, and it renders search_snippet — a "where the match was found in the chat body" line — exactly the way VS Code's Search view shows matching lines. It is a content search, not a name-only quick-open.

Worth noting this separation was the original design intent and got lost. #1059 explicitly proposed ⌘⇧F for session search and argued for leaving ⌘K free for a future palette; PR #1064 took that path but was never merged (still open). #1385 then shipped the palette and absorbed session search into it. The net result is that ⌘⇧F is bound to nothing in web/src/ today, and #1059 is still open describing behavior that does not exist.

Proposed solution

Split the one surface into two keyed entry points, keeping the existing dialog component and its server-search plumbing.

⌘K / Ctrl+K — Command palette. Actions only. Drop the Sessions group, drop IDLE_SESSION_LIMIT and the idle-cap workaround with it, and change the placeholder to Run a command. No session fetch on open.

⌘⇧F / Ctrl+Shift+F — Search sessions. Sessions only, backed by the same useConversations(query, true) server search, snippet highlighting, and archived-row filtering that exists now. Placeholder Search sessions. This becomes the target of the sidebar's magnifier button (data-testid=\"sidebar-search-button\"), so that affordance lands on a search surface rather than on the command list.

Implementation shape: keep one CommandPalette component and give it a mode: \"commands\" | \"sessions\" prop; AppShell holds the mode alongside the existing commandPaletteOpen state. That keeps the dialog chrome, cmdk config (shouldFilter={false}, vimBindings={false}) and the debounce in one place.

The ⌘⇧F hotkey should reuse the guards useCommandPaletteHotkey already implements: bail when focus is inside .xterm or .monaco-editor, ignore e.repeat, and stay disabled in embedded mode.

Both rows go into the keyboard-shortcuts dialog — the existing Open command palette · ⌘K row stays, and a Search sessions · ⌘⇧F row joins it.

Acceptance criteria

• ⌘K opens a palette listing app commands only; no session request is issued.
• ⌘⇧F opens session search with the current server-backed behavior (debounced query, content snippets, archived excluded) and navigates on select.
• The sidebar magnifier button opens session search, not the command list.
• Both shortcuts appear in the keyboard-shortcuts dialog.
• Neither shortcut fires when focus is in a terminal or the Monaco editor; both are inert in embedded mode.
• Vitest coverage for the new hotkey and for each mode's contents; the existing CommandPalette.test.tsx and useCommandPaletteHotkey.test.tsx cases updated.

Follow-up, deliberately out of scope

VS Code lets you type > in Quick Open to pivot to the command palette without re-keying. Worth adding to session search later, but it is polish on top of the split rather than part of it.

Alternatives considered

• Leave it as one surface and reorder the groups (Actions first). Cheaper, but it only trades which task gets pushed below the fold, and it leaves the sidebar's search button opening a command list. It also doesn't give session search a key of its own.
• Prefix filtering inside the single ⌘K palette (> for commands, bare text for sessions, as VS Code's Quick Open does). This is coherent, but it makes session search reachable only through the key that VS Code users read as "command palette", and still leaves ⌘⇧F — the key those users reach for to search content — unbound.
• Bind session search to ⌘P instead of ⌘⇧F. Closer to VS Code's Quick Open key, but ⌘P is Print in every browser, and Omnigent's session search matches chat content with snippet output, which is ⌘⇧F behavior, not ⌘P behavior.
• Re-restore the sidebar's inline search input (the pre-[Feature] Global command palette (Cmd/Ctrl+K) #1385 behavior) instead of a dialog. Rejected: the dialog's server-backed search already beats the old client-side filter over one page, and a second search surface would just re-fragment the UI.

[omnigent-ci]

🤖 Automated triage

• Bot assessment: Medium impact
• Priority: P2-medium
• Why: This is a useful web UI workflow improvement that separates command execution from session content search, while existing functionality remains available as a reasonable workaround.

This automated assessment uses the issue content and repository signals. Maintainers can override the priority label.