Cmd+F / `app.search` shortcut doesn't activate session search (works only via the sidebar button)

[DragonnZhang]

Summary

The Search action (app.search, bound to Cmd/Ctrl+F) does not activate the
session-list search box when triggered by its keyboard shortcut — reported to fail
from any screen, including the chat view. The same search does work when
invoked from the sidebar's in-navigator "Search" menu item.

Because the command palette (#41 / #42) invokes the app's own app.search action,
its Search entry inherits this bug too. This issue is about the underlying
app.search defect, which pre-dates and is independent of the command palette.

Repro

1. Open the app.
2. Press Cmd+F (macOS) / Ctrl+F anywhere (chat view, etc.).
   • Expected: the session-list search box appears and is focused.
   • Actual: nothing happens.
3. Contrast: open the sidebar's Chats filter dropdown → click Search.
   • The search box appears correctly.

Investigation so far

Static analysis shows the two paths should be identical, yet they diverge:

• There is exactly one app.search handler
  (AppShell.tsx:1309 → () => setSearchActive(true)) and exactly one
  searchActive state (AppShell.tsx:1225). The working sidebar button
  (AppShell.tsx:4584) calls the same setSearchActive(true).
• useSessionSearch.ts:377 focuses the search input whenever searchActive
  flips to true, regardless of who set it.
• No native-menu Cmd+F accelerator and no before-input-event /
  globalShortcut interception exists in the main process, so the keystroke
  should reach the renderer's capture-phase keydown listener in the action
  registry.

So by code the shortcut should behave like the button. The divergence must be a
runtime condition (focus/zone/render state) that a headless CI run can't
reproduce — the e2e sandbox has no sessions, so SessionList doesn't render
the search header even when searchActive is set, making this invisible to the
existing harness.

Plan

• Reproduce locally with a seeded session so SessionList actually renders
  the search header, then diff the button path vs. the app.search /
  registry-execute path to find the real cause (likely focus/zone or a
  re-render/reset timing difference).
• Fix app.search so it robustly activates + focuses search from any context
  (keyboard shortcut and command palette), and add a CDP assertion that seeds a
  session and asserts the search box appears from the shortcut.
• Ship as its own PR (not folded into the command-palette PR).

Part of the autonomous desktop-feature loop (loop-bot).

[DragonnZhang]

Root cause found: this is macOS-specific — app.search itself is correct

I instrumented the app.search handler + searchActive state and drove the real
built app over CDP on Linux, testing both a synthetic window.dispatchEvent
and a real key event through Electron's native input pipeline
(Input.dispatchKeyEvent, Ctrl+F):

BASELINE   __appSearchRan = 0
real Ctrl+F  __appSearchRan = 1   __searchActive = true
synthetic    __appSearchRan = 2

So on Linux, Cmd/Ctrl+F works end-to-end: the registry's capture-phase
keydown listener fires app.search, which flips searchActive to true. The
handler and the state are fine. (The earlier "No sessions yet stays visible"
signal was a red herring — with zero sessions the SessionSearchHeader doesn't
render even though searchActive is true; the state was actually flipping.)

Since a real key event reaches the renderer on Linux, the reported failure must be
macOS-specific: on macOS the Cmd+F keystroke is consumed before it reaches
the renderer's keydown listener (classic macOS behavior — the native text
system grabs Cmd+F for its Find bar when focus is in an editable field; there is
no Find menu item to claim it explicitly). This cannot be reproduced or verified
on the headless-Linux CI/cloud environment.

Proposed fix (needs macOS verification)

Add a native Cmd+F handler at the main-process level so the shortcut is captured
regardless of focus, then route it to app.search:

• Add a Find item to the Edit menu (or a hidden accelerator) with
  accelerator: 'CmdOrCtrl+F' and registerAccelerator: true, whose click
  sends an IPC that triggers the existing app.search action in the renderer —
  mirroring how the app already bridges other menu accelerators.

The Linux path already works, so this fix must be verified on macOS (real
Cmd+F from the chat view shows the session search box).

Note on the command palette

The palette's Search entry calls execute('app.search') directly (it does
not depend on the Cmd+F keystroke), and execute('app.search') was verified
to set searchActive = true. With the palette fix in #42 (only-runnable-actions +
run-after-close), selecting Search from ⌘K should show the session search
box on a build with sessions — worth re-testing on the loop/command-palette
branch. If it still fails on macOS, that would point at the same searchActive → SessionSearchHeader render path and can be tracked here.

---

Generated by Claude Code