Add a quick palette command for the server and daemon logs - #2273
Open
andrewkchan wants to merge 3 commits into
Open
Add a quick palette command for the server and daemon logs#2273andrewkchan wants to merge 3 commits into
andrewkchan wants to merge 3 commits into
Conversation
The desktop log viewer had exactly one entry point: the Window ▸ Server & Daemon Logs menu item. The renderer had no way to reach it — the desktop bridge carried no method for it, and the app-command channel runs the other way (main → renderer, for menu items) — so the quick palette could not offer it at all. Add the missing renderer→main hop and hang a palette row on it: - `BbDesktopApi.openServerDaemonLogs()` (optional, for version skew) over a new `bb-desktop:open-server-daemon-logs` channel, handled in main by the existing `openServerDaemonLogs()`. That function re-checks availability, so a renderer with a stale snapshot cannot force a viewer open. - `serverDaemonLogsAvailable` on `BbDesktopInfo`, computed in `getCurrentDesktopInfo()` and re-pushed from `setCurrentRuntime` so switching to an attached runtime withdraws the entry the same moment it disables the menu item. - `logs.openServerDaemon`, shipped unbound (null shortcut, desktopOnly, macPlatform) so a diagnostics action stays out of the chord space while remaining listable and assignable. `useServerDaemonLogsCommand` registers the handler only when the shell reports logs and exposes the bridge method; registration is the palette's availability gate, so the web build, Linux, attached runtimes, and older preloads get no row rather than a dead one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drop the configuration.md shortcut row and the default-keybinding assertion: the command is minor enough that neither earns its maintenance. Cut the hook test to the two cases that matter — the command opens the viewer when the shell reports logs, and is absent when it does not — and shorten the contract comments to what the types do not already say. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The new logs.openServerDaemon app command id widens AppCommandId, which the SDK re-exports through its bundled types, so the published .d.ts changes and 0.4.14 would never carry it to npm consumers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
andrewkchan
force-pushed
the
desktop-logs-palette-command
branch
from
August 22, 2026 04:28
01275c1 to
5cb2ae8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
This just makes the
View > Server Daemon Logsbutton into a dev action that I can run from the quick paletteWhat was wrong
The desktop log viewer had exactly one entry point: the Window ▸ Server & Daemon Logs menu item (
apps/desktop/src/menu.ts). The renderer could not open it, and not because of a missing wire-up on the palette side —BbDesktopApicarried no method for it, and the only app-command channel runs the other way (main → renderer, so native menu items can dispatch into React). So the log viewer was reachable by mouse through one menu and by nothing else, which is the wrong shape for a keyboard-first diagnostics action.What changed
One new RPC, plus a palette row hung on it.
The RPC
packages/desktop-contract/src/info.ts:BbDesktopApi.openServerDaemonLogs?(): Promise<void>, optional for version skew like the other recent bridge members.apps/desktop/src/desktop-window-command-ipc.ts+preload.ts+main.ts: a newbb-desktop:open-server-daemon-logschannel whose main-side handler just calls the existingopenServerDaemonLogs(). That function re-checks its own gate, so a renderer holding a stale info snapshot cannot force a viewer open for a runtime that has none.Availability
serverDaemonLogsAvailableonbbDesktopInfoSchema, computed ingetCurrentDesktopInfo()from the sameshouldEnableServerDaemonLogsMenu()predicate the menu uses, and re-pushed fromsetCurrentRuntime()so switching to an attached runtime withdraws the palette entry at the same moment it disables the menu item.The palette row
logs.openServerDaemoninAPP_COMMAND_IDS, shipped viaunassignedBinding(null shortcut,desktopOnly,macPlatform): a diagnostics action stays out of the chord space while remaining listable in the palette and assignable in Settings → Keyboard.apps/app/src/hooks/useServerDaemonLogsCommand.tsregisters the handler only when the shell reports logs and exposes the bridge method. Handler registration is whatisCommandAvailablegates on, so the web build, Linux, attached runtimes, and older preloads all get no row rather than a row that silently no-ops.docs/configuration.mdshortcut table gains the row.No wire changes between server and host daemon, so
HOST_DAEMON_PROTOCOL_VERSIONis untouched. CLI/SDK parity is deliberately skipped: the command opens a native window on the machine running the desktop shell, so there is no meaningful remote equivalent — the CLI-side access to the same data is the files under~/.bb/logs/.How you verified
Tests added (all fail before, pass after):
apps/app/src/hooks/useServerDaemonLogsCommand.test.tsx— offers the command and opens the viewer; stays unavailable for an attached runtime; withdraws the command when the shell switches to an attached runtime mid-session; stays unavailable on a preload that predates the bridge method. Mutation-checked: replacing theenabledgate withtruefails 3 of the 4.apps/desktop/test/preload-browser-api.test.ts— the bridge method invokes the fixed channel, and a pushed info payload updatesserverDaemonLogsAvailablerather than the startup snapshot.apps/server/test/system/app-keybindings.test.ts— the shipped default is unbound,desktopOnly,macPlatform-scoped, and available to desktop-mac clients only.Commands run:
pnpm exec turbo run typecheck --filter=@bb/domain --filter=@bb/desktop-contract --filter=@bb/app --filter=@bb/desktop --filter=@bb/server— green.@bb/desktop230 passed,@bb/app3260 passed,@bb/server1906 passed.oxlintandoxfmt --checkclean on the changed files.Two unrelated local failures, each confirmed pre-existing by re-running with these changes stashed:
PluginIcon.test.tsxand 17 plugin-bundle/artifact tests in the server, all tracing to a staleplugins/monaco/directory in the working tree with nopackage.json.apps/desktop/test/preload-build.test.tsadditionally cannot launch Electron inside the agent sandbox; it passes when run outside it.