Problem
projects.tree (and projects.project_sessions) in tui_gateway/server.py read the gateway process's launch HERMES_HOME profile and take no profile param. The machine-dashboard is launched hard-pinned to the default profile (-p default, re-exec'd so the sticky active_profile file can't reroute it), and --open-profile only preselects a profile in the UI. So a client connected to the machine-dashboard (e.g. Hermes for Android over Tailscale) can only ever see the default profile's project tree — never the profile it's actually viewing. Desktop avoids this by using per-profile backends, but those are loopback-only.
Result on mobile: the Projects view shows the default profile's tree (often 1 project) regardless of the selected profile.
Requested change
Add an optional profile param to projects.tree and projects.project_sessions and scope the read to it, using the existing per-call HERMES_HOME override mechanism (_profile_scoped / set_hermes_home_override ContextVar) that other RPCs already use. When profile is provided, resolve _get_db() / get_hermes_home() (and projects_db) against that profile for the duration of the call; when omitted, keep today's launch-profile behavior for back-compat.
This lets a single machine-dashboard serve any profile's project tree to network clients, matching desktop's per-profile view.
Client side (already shipped as a stopgap)
Hermes for Android currently works around this by deriving Projects client-side from the cross-profile session list (grouping by git repo root / cwd across all profiles). Once the gateway accepts a profile param, re-wire ProjectsRepository.tree()/projectSessions() to pass the active profile and restore true per-profile, server-authoritative projects (explicit + discovered tiers included).
Notes
- Intended for upstream contribution to
NousResearch/hermes-agent.
- Mechanism reference:
hermes_constants.get_hermes_home() (ContextVar override), tui_gateway/server.py @method("projects.tree") (~L11224), _get_db() (~L972), hermes_cli/projects_db.py projects_db_path().
Problem
projects.tree(andprojects.project_sessions) intui_gateway/server.pyread the gateway process's launchHERMES_HOMEprofile and take noprofileparam. The machine-dashboard is launched hard-pinned to thedefaultprofile (-p default, re-exec'd so the stickyactive_profilefile can't reroute it), and--open-profileonly preselects a profile in the UI. So a client connected to the machine-dashboard (e.g. Hermes for Android over Tailscale) can only ever see the default profile's project tree — never the profile it's actually viewing. Desktop avoids this by using per-profile backends, but those are loopback-only.Result on mobile: the Projects view shows the default profile's tree (often 1 project) regardless of the selected profile.
Requested change
Add an optional
profileparam toprojects.treeandprojects.project_sessionsand scope the read to it, using the existing per-callHERMES_HOMEoverride mechanism (_profile_scoped/set_hermes_home_overrideContextVar) that other RPCs already use. Whenprofileis provided, resolve_get_db()/get_hermes_home()(andprojects_db) against that profile for the duration of the call; when omitted, keep today's launch-profile behavior for back-compat.This lets a single machine-dashboard serve any profile's project tree to network clients, matching desktop's per-profile view.
Client side (already shipped as a stopgap)
Hermes for Android currently works around this by deriving Projects client-side from the cross-profile session list (grouping by git repo root / cwd across all profiles). Once the gateway accepts a
profileparam, re-wireProjectsRepository.tree()/projectSessions()to pass the active profile and restore true per-profile, server-authoritative projects (explicit + discovered tiers included).Notes
NousResearch/hermes-agent.hermes_constants.get_hermes_home()(ContextVar override),tui_gateway/server.py@method("projects.tree")(~L11224),_get_db()(~L972),hermes_cli/projects_db.pyprojects_db_path().