[kitlangton]

⌘K did nothing on the Settings page.

Cause: the shortcut only works when some route has registered a command.palette command. Home, sessions and the new session screen each register their own, but the Settings route registered none, so the shortcut found nothing to run there.

Fix: the shell now registers the Home palette (commands, sessions, settings) as a fallback that every route gets. Every palette registration now shares the palette key, so the newest surface wins: sessions and new session keep their file palette, and Home's sessions view keeps its focused-server palette. Home's start page now uses the shell's copy instead of its own duplicate.

Surfaces checked:

• Settings: fixed.
• Home, session and new session: unchanged.
• Terminal: unchanged. The shortcut listener runs on document in the capture phase, before the terminal sees the key.
• Browser pane: unchanged on purpose. The page keeps ⌘K, as covered by browser-pane-restore.spec.ts.
• Dialogs: unchanged. An open dialog still blocks shortcuts.

Test: e2e/regression/command-palette.spec.ts gains "opens from the Settings page and finds another setting". It opens Settings with ⌘, , presses ⌘K, searches "theme", and checks that Settings moves to Appearance with the Theme row in view.

[opencode-agent]

I recommend merging this. I ran e2e/regression/command-palette.spec.ts on both branches. The new Settings test fails on the base, where ⌘K does nothing on Settings, and passes with this change. Both branches fail the same 3 other tests in that spec, so those failures are not caused by this change. tsc -b and the command unit tests pass.

The registry keeps the newest registration per key, so the shell's palette has the lowest priority: routes that register their own still take over, and the shell's is used again when they unmount.

Public API: unchanged. Only internal registration keys in packages/app changed.

No blocking concerns.