Summary
The composer state/queries/mutation that #243 added for the workspace catalog (following the ask in #340 and the maintainer's own reply in #264 that a live switcher would need a separate feature request) are present in src/screens/chat/components/chat-composer.tsx, but the actual button + dropdown were never added to the JSX. So on the currently shipped build (v2.3.0), there is still no way to switch the active workspace from the UI without restarting the server / editing state on disk.
Evidence (v2.3.0, main @ the commit this repo currently ships)
workspaceButtonLabel (computed ~L1186-1190) — never referenced anywhere else in the file.handleOpenWorkspaceManager (~L1169) — defined, never called. It doesn't even open a workspace UI; it just emits SEARCH_MODAL_EVENTS.TOGGLE_FILE_EXPLORER.workspaceMenuRef (~L953) — declared, never attached to a DOM node.isWorkspaceMenuOpen — set to false in a couple of places but never set to true, and never included in the outside-click-to-close effect (unlike isProfileMenuOpen/isModelMenuOpen/isThinkingMenuOpen, which all are).workspaceSelectMutation (~L1078-1101) — fully implemented and correct (POST /api/workspace, invalidates the right query key, closes the menu on success). It's just never called from anywhere, since nothing renders a control that would call it.
Confirmed via git log -p -S workspaceButtonLabel that this has been the state since the squashed v2 history — i.e. it shipped this way and nobody's flagged the specific rendering gap yet, as opposed to the general "can I switch workspaces" question in #264/#340.
Impact
Anyone running a zero-fork install against a single hermes-agent gateway is stuck with exactly one workspace root (HERMES_WORKSPACE_DIR / the auto-detected default) for the Files panel and agent file tools. Working across more than one project means manually editing ~/.hermes/webui_state/workspaces.json (or calling POST /api/workspace by hand) and reloading — there's no in-app affordance at all, even though every other piece the UI needs already works.
Fix
Opening a PR right after this issue that adds the missing button/dropdown (modeled on the adjacent, working profile selector) and wires isWorkspaceMenuOpen into the outside-click handler and sibling menu-close calls. No changes to state/query/mutation logic were needed — it was all already correct, just unreachable from the UI. Verified end-to-end against a live gateway with 5 registered workspaces: switching updates the composer label and the Files panel's contents immediately.
Summary
The composer state/queries/mutation that #243 added for the workspace catalog (following the ask in #340 and the maintainer's own reply in #264 that a live switcher would need a separate feature request) are present in
src/screens/chat/components/chat-composer.tsx, but the actual button + dropdown were never added to the JSX. So on the currently shipped build (v2.3.0), there is still no way to switch the active workspace from the UI without restarting the server / editing state on disk.Evidence (v2.3.0,
main@ the commit this repo currently ships)workspaceButtonLabel(computed ~L1186-1190) — never referenced anywhere else in the file.handleOpenWorkspaceManager(~L1169) — defined, never called. It doesn't even open a workspace UI; it just emitsSEARCH_MODAL_EVENTS.TOGGLE_FILE_EXPLORER.workspaceMenuRef(~L953) — declared, never attached to a DOM node.isWorkspaceMenuOpen— set tofalsein a couple of places but never set totrue, and never included in the outside-click-to-close effect (unlikeisProfileMenuOpen/isModelMenuOpen/isThinkingMenuOpen, which all are).workspaceSelectMutation(~L1078-1101) — fully implemented and correct (POST /api/workspace, invalidates the right query key, closes the menu on success). It's just never called from anywhere, since nothing renders a control that would call it.Confirmed via
git log -p -S workspaceButtonLabelthat this has been the state since the squashed v2 history — i.e. it shipped this way and nobody's flagged the specific rendering gap yet, as opposed to the general "can I switch workspaces" question in #264/#340.Impact
Anyone running a zero-fork install against a single
hermes-agentgateway is stuck with exactly one workspace root (HERMES_WORKSPACE_DIR/ the auto-detected default) for the Files panel and agent file tools. Working across more than one project means manually editing~/.hermes/webui_state/workspaces.json(or callingPOST /api/workspaceby hand) and reloading — there's no in-app affordance at all, even though every other piece the UI needs already works.Fix
Opening a PR right after this issue that adds the missing button/dropdown (modeled on the adjacent, working profile selector) and wires
isWorkspaceMenuOpeninto the outside-click handler and sibling menu-close calls. No changes to state/query/mutation logic were needed — it was all already correct, just unreachable from the UI. Verified end-to-end against a live gateway with 5 registered workspaces: switching updates the composer label and the Files panel's contents immediately.