feat(dashboard): unify multi-profile management — one machine dashboard, global profile switcher by teknium1 · Pull Request #44007 · NousResearch/hermes-agent

teknium1 · 2026-06-11T05:03:24Z

Summary

The dashboard becomes ONE machine-level management surface with a global profile switcher: config, API keys, MCPs, model, skills, and even the Chat tab read/write whichever profile the switcher targets, and <profile> dashboard routes to the machine dashboard instead of fragmenting into per-profile servers.

Builds on #43808 (profile-scoped skills/toolsets): same _profile_scope() seam, generalized to the remaining management families, plus the launch unification and the single global selector that replaces page-local pickers.

Changes

hermes_cli/web_server.py: profile param (query or body) on /api/config (get/put/raw), /api/env (get/put/delete/reveal), /api/mcp/servers (list/add/remove/test/enabled), /api/mcp/catalog (list/install), /api/model/info, /api/model/set. model/set restructured so the expensive-model await runs before the scope and the config write runs synchronously inside it (worker thread) — the scope is never held across an await. MCP git-bootstrap installs spawn hermes -p <profile> mcp install. Chat PTY: ?profile= on /api/pty points the child's HERMES_HOME at the profile dir (own gateway subprocess; config/skills/memory/state.db all profile-bound; in-process gateway attach skipped when scoped). start_server(initial_profile=…) appends ?profile= to the auto-open URL.
hermes_cli/main.py + subcommands/dashboard.py: unified launch routing — worker dashboard attaches to a listening machine dashboard (opens browser at ?profile=worker) or re-execs as the machine dashboard pinned to the default profile with --open-profile worker preselecting the switcher. --isolated preserves the old dedicated-server behavior. Re-exec guard: a child carrying --open-profile never re-routes (no exec loop).
web/src/: ProfileProvider + sidebar ProfileSwitcher — ONE selector, URL-persisted (?profile=), mirrored into fetchJSON which auto-appends the param to the scoped endpoint families (explicit params always win; non-scoped families — sessions, ops, cron, pairing — are never rewritten). App-wide amber banner names the managed profile. SkillsPage's page-local selector (from feat(dashboard): profile-scoped skills & toolsets management #43808) folded into the global context. ChatPage threads the scope into the PTY WS URL; switching profiles remounts the terminal into a fresh scoped session.

Omitted/empty profile keeps exact legacy behavior on every endpoint.

Validation

Check	Result
New tests (`test_web_server_profile_unification.py`, 15)	config/env/MCP/model scoped reads+writes land in target profile only; query-param ≡ body; PTY env scoping; ghost profile → 404
New tests (`test_dashboard_unified_launch.py`, 5)	attach-when-listening, re-exec argv (`-p default --open-profile worker`, HERMES_HOME dropped), `--isolated` skip, default-profile skip, no exec loop
Existing suites	297/297 across web_server + skills-profiles + pty-import (6 PTY test fakes updated for the new kwarg)
E2E (real imports, temp HERMES_HOME, 2 profiles)	all 7 checks pass — writes isolated per profile, module globals restored, chat env binds profile home
`tsc -b` + `vite build`	green; new strings confirmed in built bundle

Infographic

…rd, global profile switcher The dashboard becomes a machine-level management surface with one write-target selector, replacing per-profile dashboard fragmentation. Backend: - profile param (query or body) on /api/config (get/put/raw), /api/env (get/put/delete/reveal), /api/mcp/servers (list/add/remove/test/enabled), /api/mcp/catalog (list/install), /api/model/info, /api/model/set — all scoped through the existing _profile_scope() context manager - model/set restructured: expensive-model warning (await) runs before the scope; the config write runs sync inside the scope in a worker thread - MCP catalog installs + git-bootstrap entries spawn 'hermes -p <profile>' - chat PTY: ?profile= on /api/pty points the child's HERMES_HOME at the profile dir (its own gateway subprocess, config/skills/memory/state.db all profile-bound); in-process gateway attach skipped when scoped CLI launch unification: - '<profile> dashboard' routes to the machine dashboard: attach (open browser at ?profile=) when one is listening, else re-exec pinned to the default profile with --open-profile preselecting the launcher - --isolated preserves the old dedicated per-profile server behavior - start_server(initial_profile=...) appends ?profile= to the auto-open URL Frontend: - ProfileProvider + sidebar ProfileSwitcher: ONE global selector, URL- persisted (?profile=), mirrored into fetchJSON which auto-appends the param to the scoped endpoint families (explicit params win) - app-wide amber banner names the managed profile - SkillsPage's page-local selector (from the skills-scoping PR) folded into the global context — single source of truth - ChatPage threads the scope into the PTY WS URL; switching profiles remounts the terminal into a fresh scoped session Omitted profile keeps legacy behavior everywhere.

github-actions · 2026-06-11T05:04:30Z

🔎 Lint report: `hermes/hermes-a0bb182b` vs `origin/main`

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 10683 on HEAD, 10680 on base (🆕 +3)

🆕 New issues (3):

Rule	Count
`unresolved-import`	3

First entries

tests/hermes_cli/test_web_server_profile_unification.py:35: [unresolved-import] unresolved-import: Cannot resolve imported module `starlette.testclient`
tests/hermes_cli/test_web_server_profile_unification.py:9: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`
tests/hermes_cli/test_dashboard_unified_launch.py:10: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`

✅ Fixed issues: none

Unchanged: 5583 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

- web-dashboard.md: 'Managing multiple profiles' section (switcher, URL deep-links, unified launch, --isolated, scoped Chat, what stays per-profile) + --isolated in the options table - profiles.md: 'From the dashboard' subsection + set-as-active vs switcher clarification - cli-commands.md: --isolated flag + profile-alias launch example

Review findings (dev review on PR #44007): 1. HIGH — stale page state on profile switch: pages load data on mount and didn't consume the profile scope, so a page opened under profile A kept showing A's state while writes silently targeted the newly selected B. Fixed structurally: ProfileKeyedRoutes wraps the routed page tree and keys it by the selected profile, remounting every page (fresh state + refetch) on switch. ChatPage keeps its own remount (channel keyed on scopedProfile). 2. HIGH — /api/model/auxiliary read was unscoped while /api/model/set wrote scoped (Models page could show default's aux pins while editing worker's). Endpoint now takes profile + _profile_scope, added to PROFILE_SCOPED_PREFIXES, HTTPException re-raise so ghost profiles 404 instead of 500. Regression test asserts read/write symmetry with differing worker/default aux config. 3. MEDIUM — tools post-setup spawned unscoped from the profile-aware drawer. Now spawns 'hermes -p <profile> tools post-setup <key>' (same mechanism as hub installs); drawer threads its profile prop. Most hooks install machine-level artifacts where the scope is inert, but hooks reading config/env now see the drawer's HERMES_HOME. 4. LOW — ty warnings: env Optional asserts before subscript/membership, fastapi import replaced with web_server.HTTPException re-use. 298 tests green across the four affected suites; tsc -b + vite build green; aux scoping E2E-verified with real imports.

1. BLOCKER — profile scope dropped on sidebar navigation: ProfileProvider derived the selection from the current URL, and nav links are bare paths, so clicking Config from /skills?profile=worker silently reset the write target. State is now the source of truth; an effect re-asserts ?profile= onto the new location after every navigation (URL stays a synchronized projection for deep links/refresh), and an incoming URL param (e.g. 'Manage skills & tools' links) still wins. 2. BLOCKER — /api/model/options unscoped while model/set wrote scoped: the picker context (current model/provider, custom providers, per-profile .env auth state) now loads inside _profile_scope; added to PROFILE_SCOPED_PREFIXES. Test: a worker-only current-model pin appears in the scoped payload and not the unscoped one. 3. BLOCKER — MCP test-server probe escaped the scope after the config read: the probe now re-enters _profile_scope inside the worker thread so env-placeholder expansion resolves against the selected profile's .env. Known limit (documented): the probe's dedicated MCP event-loop thread doesn't inherit the contextvar (OAuth token paths). Test asserts get_hermes_home() inside the probe == the worker profile dir. 4. BLOCKER — broad excepts swallowed unknown-profile 404s: /api/model/info degraded to 200-with-empty-model-info and /api/mcp/catalog to a silently-empty catalog. Both re-raise HTTPException; 404 regression tests added for info/options/catalog. Polish: scope banner clears the fixed mobile header (mt-14 lg:mt-0); --open-profile hidden via argparse.SUPPRESS (internal re-exec flag); attach-path test now asserts the opened ?profile= URL. (Stale-page-state + /api/model/auxiliary findings from this review were already fixed in 92bcd15 — the review ran against e600f69.) 35 tests in the two new suites + 274 in the adjacent ones, all green; tsc -b + vite build green; scoping E2E-verified with real imports.

…rofile-param tip, body-beats-query precedence Docs: - web-dashboard.md: add the missing 'Profiles' subsection to Pages (cards, create/builder, manage-skills jump, set-as-active vs switcher distinction, editors); REST API section gets a profile-scoped-endpoints tip documenting ?profile= / body profile / 404 semantics / /api/pty - (profiles.md + cli-commands.md were already updated in e600f69) Precedence fix: scoped endpoints taking BOTH a query param and a body field now resolve body.profile first. The SPA's fetchJSON injects the query param from the GLOBAL switcher; an explicit body.profile (e.g. Profile Builder flows writing into a specific new profile) is the more specific intent and must not be overridden by whatever the sidebar happens to be set to. Matches the documented 'explicit beats global' contract in api.ts. Verified: 304 tests green across the four suites; tsc -b + vite build green; docusaurus build green (only pre-existing broken-link warnings, none from this PR's pages).

) * fix(mcp): propagate HERMES_HOME override onto the MCP event loop Closes the known limit documented in #44007: tasks scheduled via run_coroutine_threadsafe are created INSIDE the MCP loop thread, so they copy that thread's context — a per-request profile scope (dashboard ?profile= endpoints, e.g. the MCP 'Test server' probe) silently vanished for anything resolving get_hermes_home() inside the coroutine. Most visible symptom: OAuth token-store paths (HERMES_HOME/mcp-tokens/) resolved against the process home instead of the selected profile, so testing an OAuth MCP cross-profile read the wrong tokens. _run_on_mcp_loop now wraps scheduled coroutines with the caller's context-local override (_wrap_with_home_override): set inside the task's own context on the loop, reset on completion — task-local, so concurrent calls carrying different scopes don't interfere, and the loop thread's default context stays untouched. No-op (coroutine passes through unwrapped) when no override is active, i.e. every non-dashboard caller. web_server's probe comment updated from 'known limit' to 'covered'. Tests: override propagation (direct + factory form), OAuth token-path resolution on the loop, loop-context cleanliness after scoped calls, no-op passthrough. 225 green across mcp_tool + unification suites. * test(mcp): concurrent different-scope calls don't interfere

…rd, global profile switcher (#44007) * feat(dashboard): unify multi-profile management — one machine dashboard, global profile switcher The dashboard becomes a machine-level management surface with one write-target selector, replacing per-profile dashboard fragmentation. Backend: - profile param (query or body) on /api/config (get/put/raw), /api/env (get/put/delete/reveal), /api/mcp/servers (list/add/remove/test/enabled), /api/mcp/catalog (list/install), /api/model/info, /api/model/set — all scoped through the existing _profile_scope() context manager - model/set restructured: expensive-model warning (await) runs before the scope; the config write runs sync inside the scope in a worker thread - MCP catalog installs + git-bootstrap entries spawn 'hermes -p <profile>' - chat PTY: ?profile= on /api/pty points the child's HERMES_HOME at the profile dir (its own gateway subprocess, config/skills/memory/state.db all profile-bound); in-process gateway attach skipped when scoped CLI launch unification: - '<profile> dashboard' routes to the machine dashboard: attach (open browser at ?profile=) when one is listening, else re-exec pinned to the default profile with --open-profile preselecting the launcher - --isolated preserves the old dedicated per-profile server behavior - start_server(initial_profile=...) appends ?profile= to the auto-open URL Frontend: - ProfileProvider + sidebar ProfileSwitcher: ONE global selector, URL- persisted (?profile=), mirrored into fetchJSON which auto-appends the param to the scoped endpoint families (explicit params win) - app-wide amber banner names the managed profile - SkillsPage's page-local selector (from the skills-scoping PR) folded into the global context — single source of truth - ChatPage threads the scope into the PTY WS URL; switching profiles remounts the terminal into a fresh scoped session Omitted profile keeps legacy behavior everywhere. * docs(dashboard): document machine-level multi-profile management - web-dashboard.md: 'Managing multiple profiles' section (switcher, URL deep-links, unified launch, --isolated, scoped Chat, what stays per-profile) + --isolated in the options table - profiles.md: 'From the dashboard' subsection + set-as-active vs switcher clarification - cli-commands.md: --isolated flag + profile-alias launch example * fix(dashboard): address profile-unification review findings Review findings (dev review on PR #44007): 1. HIGH — stale page state on profile switch: pages load data on mount and didn't consume the profile scope, so a page opened under profile A kept showing A's state while writes silently targeted the newly selected B. Fixed structurally: ProfileKeyedRoutes wraps the routed page tree and keys it by the selected profile, remounting every page (fresh state + refetch) on switch. ChatPage keeps its own remount (channel keyed on scopedProfile). 2. HIGH — /api/model/auxiliary read was unscoped while /api/model/set wrote scoped (Models page could show default's aux pins while editing worker's). Endpoint now takes profile + _profile_scope, added to PROFILE_SCOPED_PREFIXES, HTTPException re-raise so ghost profiles 404 instead of 500. Regression test asserts read/write symmetry with differing worker/default aux config. 3. MEDIUM — tools post-setup spawned unscoped from the profile-aware drawer. Now spawns 'hermes -p <profile> tools post-setup <key>' (same mechanism as hub installs); drawer threads its profile prop. Most hooks install machine-level artifacts where the scope is inert, but hooks reading config/env now see the drawer's HERMES_HOME. 4. LOW — ty warnings: env Optional asserts before subscript/membership, fastapi import replaced with web_server.HTTPException re-use. 298 tests green across the four affected suites; tsc -b + vite build green; aux scoping E2E-verified with real imports. * fix(dashboard): address second profile-unification review (gille) 1. BLOCKER — profile scope dropped on sidebar navigation: ProfileProvider derived the selection from the current URL, and nav links are bare paths, so clicking Config from /skills?profile=worker silently reset the write target. State is now the source of truth; an effect re-asserts ?profile= onto the new location after every navigation (URL stays a synchronized projection for deep links/refresh), and an incoming URL param (e.g. 'Manage skills & tools' links) still wins. 2. BLOCKER — /api/model/options unscoped while model/set wrote scoped: the picker context (current model/provider, custom providers, per-profile .env auth state) now loads inside _profile_scope; added to PROFILE_SCOPED_PREFIXES. Test: a worker-only current-model pin appears in the scoped payload and not the unscoped one. 3. BLOCKER — MCP test-server probe escaped the scope after the config read: the probe now re-enters _profile_scope inside the worker thread so env-placeholder expansion resolves against the selected profile's .env. Known limit (documented): the probe's dedicated MCP event-loop thread doesn't inherit the contextvar (OAuth token paths). Test asserts get_hermes_home() inside the probe == the worker profile dir. 4. BLOCKER — broad excepts swallowed unknown-profile 404s: /api/model/info degraded to 200-with-empty-model-info and /api/mcp/catalog to a silently-empty catalog. Both re-raise HTTPException; 404 regression tests added for info/options/catalog. Polish: scope banner clears the fixed mobile header (mt-14 lg:mt-0); --open-profile hidden via argparse.SUPPRESS (internal re-exec flag); attach-path test now asserts the opened ?profile= URL. (Stale-page-state + /api/model/auxiliary findings from this review were already fixed in 92bcd15 — the review ran against e600f69.) 35 tests in the two new suites + 274 in the adjacent ones, all green; tsc -b + vite build green; scoping E2E-verified with real imports. * docs(dashboard)+fix: self-review pass — Profiles page section, REST profile-param tip, body-beats-query precedence Docs: - web-dashboard.md: add the missing 'Profiles' subsection to Pages (cards, create/builder, manage-skills jump, set-as-active vs switcher distinction, editors); REST API section gets a profile-scoped-endpoints tip documenting ?profile= / body profile / 404 semantics / /api/pty - (profiles.md + cli-commands.md were already updated in e600f69) Precedence fix: scoped endpoints taking BOTH a query param and a body field now resolve body.profile first. The SPA's fetchJSON injects the query param from the GLOBAL switcher; an explicit body.profile (e.g. Profile Builder flows writing into a specific new profile) is the more specific intent and must not be overridden by whatever the sidebar happens to be set to. Matches the documented 'explicit beats global' contract in api.ts. Verified: 304 tests green across the four suites; tsc -b + vite build green; docusaurus build green (only pre-existing broken-link warnings, none from this PR's pages).

) * fix(mcp): propagate HERMES_HOME override onto the MCP event loop Closes the known limit documented in #44007: tasks scheduled via run_coroutine_threadsafe are created INSIDE the MCP loop thread, so they copy that thread's context — a per-request profile scope (dashboard ?profile= endpoints, e.g. the MCP 'Test server' probe) silently vanished for anything resolving get_hermes_home() inside the coroutine. Most visible symptom: OAuth token-store paths (HERMES_HOME/mcp-tokens/) resolved against the process home instead of the selected profile, so testing an OAuth MCP cross-profile read the wrong tokens. _run_on_mcp_loop now wraps scheduled coroutines with the caller's context-local override (_wrap_with_home_override): set inside the task's own context on the loop, reset on completion — task-local, so concurrent calls carrying different scopes don't interfere, and the loop thread's default context stays untouched. No-op (coroutine passes through unwrapped) when no override is active, i.e. every non-dashboard caller. web_server's probe comment updated from 'known limit' to 'covered'. Tests: override propagation (direct + factory form), OAuth token-path resolution on the loop, loop-context cleanliness after scoped calls, no-op passthrough. 225 green across mcp_tool + unification suites. * test(mcp): concurrent different-scope calls don't interfere

…rd, global profile switcher (NousResearch#44007) * feat(dashboard): unify multi-profile management — one machine dashboard, global profile switcher The dashboard becomes a machine-level management surface with one write-target selector, replacing per-profile dashboard fragmentation. Backend: - profile param (query or body) on /api/config (get/put/raw), /api/env (get/put/delete/reveal), /api/mcp/servers (list/add/remove/test/enabled), /api/mcp/catalog (list/install), /api/model/info, /api/model/set — all scoped through the existing _profile_scope() context manager - model/set restructured: expensive-model warning (await) runs before the scope; the config write runs sync inside the scope in a worker thread - MCP catalog installs + git-bootstrap entries spawn 'hermes -p <profile>' - chat PTY: ?profile= on /api/pty points the child's HERMES_HOME at the profile dir (its own gateway subprocess, config/skills/memory/state.db all profile-bound); in-process gateway attach skipped when scoped CLI launch unification: - '<profile> dashboard' routes to the machine dashboard: attach (open browser at ?profile=) when one is listening, else re-exec pinned to the default profile with --open-profile preselecting the launcher - --isolated preserves the old dedicated per-profile server behavior - start_server(initial_profile=...) appends ?profile= to the auto-open URL Frontend: - ProfileProvider + sidebar ProfileSwitcher: ONE global selector, URL- persisted (?profile=), mirrored into fetchJSON which auto-appends the param to the scoped endpoint families (explicit params win) - app-wide amber banner names the managed profile - SkillsPage's page-local selector (from the skills-scoping PR) folded into the global context — single source of truth - ChatPage threads the scope into the PTY WS URL; switching profiles remounts the terminal into a fresh scoped session Omitted profile keeps legacy behavior everywhere. * docs(dashboard): document machine-level multi-profile management - web-dashboard.md: 'Managing multiple profiles' section (switcher, URL deep-links, unified launch, --isolated, scoped Chat, what stays per-profile) + --isolated in the options table - profiles.md: 'From the dashboard' subsection + set-as-active vs switcher clarification - cli-commands.md: --isolated flag + profile-alias launch example * fix(dashboard): address profile-unification review findings Review findings (dev review on PR NousResearch#44007): 1. HIGH — stale page state on profile switch: pages load data on mount and didn't consume the profile scope, so a page opened under profile A kept showing A's state while writes silently targeted the newly selected B. Fixed structurally: ProfileKeyedRoutes wraps the routed page tree and keys it by the selected profile, remounting every page (fresh state + refetch) on switch. ChatPage keeps its own remount (channel keyed on scopedProfile). 2. HIGH — /api/model/auxiliary read was unscoped while /api/model/set wrote scoped (Models page could show default's aux pins while editing worker's). Endpoint now takes profile + _profile_scope, added to PROFILE_SCOPED_PREFIXES, HTTPException re-raise so ghost profiles 404 instead of 500. Regression test asserts read/write symmetry with differing worker/default aux config. 3. MEDIUM — tools post-setup spawned unscoped from the profile-aware drawer. Now spawns 'hermes -p <profile> tools post-setup <key>' (same mechanism as hub installs); drawer threads its profile prop. Most hooks install machine-level artifacts where the scope is inert, but hooks reading config/env now see the drawer's HERMES_HOME. 4. LOW — ty warnings: env Optional asserts before subscript/membership, fastapi import replaced with web_server.HTTPException re-use. 298 tests green across the four affected suites; tsc -b + vite build green; aux scoping E2E-verified with real imports. * fix(dashboard): address second profile-unification review (gille) 1. BLOCKER — profile scope dropped on sidebar navigation: ProfileProvider derived the selection from the current URL, and nav links are bare paths, so clicking Config from /skills?profile=worker silently reset the write target. State is now the source of truth; an effect re-asserts ?profile= onto the new location after every navigation (URL stays a synchronized projection for deep links/refresh), and an incoming URL param (e.g. 'Manage skills & tools' links) still wins. 2. BLOCKER — /api/model/options unscoped while model/set wrote scoped: the picker context (current model/provider, custom providers, per-profile .env auth state) now loads inside _profile_scope; added to PROFILE_SCOPED_PREFIXES. Test: a worker-only current-model pin appears in the scoped payload and not the unscoped one. 3. BLOCKER — MCP test-server probe escaped the scope after the config read: the probe now re-enters _profile_scope inside the worker thread so env-placeholder expansion resolves against the selected profile's .env. Known limit (documented): the probe's dedicated MCP event-loop thread doesn't inherit the contextvar (OAuth token paths). Test asserts get_hermes_home() inside the probe == the worker profile dir. 4. BLOCKER — broad excepts swallowed unknown-profile 404s: /api/model/info degraded to 200-with-empty-model-info and /api/mcp/catalog to a silently-empty catalog. Both re-raise HTTPException; 404 regression tests added for info/options/catalog. Polish: scope banner clears the fixed mobile header (mt-14 lg:mt-0); --open-profile hidden via argparse.SUPPRESS (internal re-exec flag); attach-path test now asserts the opened ?profile= URL. (Stale-page-state + /api/model/auxiliary findings from this review were already fixed in 92bcd15 — the review ran against e600f69.) 35 tests in the two new suites + 274 in the adjacent ones, all green; tsc -b + vite build green; scoping E2E-verified with real imports. * docs(dashboard)+fix: self-review pass — Profiles page section, REST profile-param tip, body-beats-query precedence Docs: - web-dashboard.md: add the missing 'Profiles' subsection to Pages (cards, create/builder, manage-skills jump, set-as-active vs switcher distinction, editors); REST API section gets a profile-scoped-endpoints tip documenting ?profile= / body profile / 404 semantics / /api/pty - (profiles.md + cli-commands.md were already updated in e600f69) Precedence fix: scoped endpoints taking BOTH a query param and a body field now resolve body.profile first. The SPA's fetchJSON injects the query param from the GLOBAL switcher; an explicit body.profile (e.g. Profile Builder flows writing into a specific new profile) is the more specific intent and must not be overridden by whatever the sidebar happens to be set to. Matches the documented 'explicit beats global' contract in api.ts. Verified: 304 tests green across the four suites; tsc -b + vite build green; docusaurus build green (only pre-existing broken-link warnings, none from this PR's pages).

…sResearch#44220) * fix(mcp): propagate HERMES_HOME override onto the MCP event loop Closes the known limit documented in NousResearch#44007: tasks scheduled via run_coroutine_threadsafe are created INSIDE the MCP loop thread, so they copy that thread's context — a per-request profile scope (dashboard ?profile= endpoints, e.g. the MCP 'Test server' probe) silently vanished for anything resolving get_hermes_home() inside the coroutine. Most visible symptom: OAuth token-store paths (HERMES_HOME/mcp-tokens/) resolved against the process home instead of the selected profile, so testing an OAuth MCP cross-profile read the wrong tokens. _run_on_mcp_loop now wraps scheduled coroutines with the caller's context-local override (_wrap_with_home_override): set inside the task's own context on the loop, reset on completion — task-local, so concurrent calls carrying different scopes don't interfere, and the loop thread's default context stays untouched. No-op (coroutine passes through unwrapped) when no override is active, i.e. every non-dashboard caller. web_server's probe comment updated from 'known limit' to 'covered'. Tests: override propagation (direct + factory form), OAuth token-path resolution on the loop, loop-context cleanliness after scoped calls, no-op passthrough. 225 green across mcp_tool + unification suites. * test(mcp): concurrent different-scope calls don't interfere

…rd, global profile switcher (NousResearch#44007) * feat(dashboard): unify multi-profile management — one machine dashboard, global profile switcher The dashboard becomes a machine-level management surface with one write-target selector, replacing per-profile dashboard fragmentation. Backend: - profile param (query or body) on /api/config (get/put/raw), /api/env (get/put/delete/reveal), /api/mcp/servers (list/add/remove/test/enabled), /api/mcp/catalog (list/install), /api/model/info, /api/model/set — all scoped through the existing _profile_scope() context manager - model/set restructured: expensive-model warning (await) runs before the scope; the config write runs sync inside the scope in a worker thread - MCP catalog installs + git-bootstrap entries spawn 'hermes -p <profile>' - chat PTY: ?profile= on /api/pty points the child's HERMES_HOME at the profile dir (its own gateway subprocess, config/skills/memory/state.db all profile-bound); in-process gateway attach skipped when scoped CLI launch unification: - '<profile> dashboard' routes to the machine dashboard: attach (open browser at ?profile=) when one is listening, else re-exec pinned to the default profile with --open-profile preselecting the launcher - --isolated preserves the old dedicated per-profile server behavior - start_server(initial_profile=...) appends ?profile= to the auto-open URL Frontend: - ProfileProvider + sidebar ProfileSwitcher: ONE global selector, URL- persisted (?profile=), mirrored into fetchJSON which auto-appends the param to the scoped endpoint families (explicit params win) - app-wide amber banner names the managed profile - SkillsPage's page-local selector (from the skills-scoping PR) folded into the global context — single source of truth - ChatPage threads the scope into the PTY WS URL; switching profiles remounts the terminal into a fresh scoped session Omitted profile keeps legacy behavior everywhere. * docs(dashboard): document machine-level multi-profile management - web-dashboard.md: 'Managing multiple profiles' section (switcher, URL deep-links, unified launch, --isolated, scoped Chat, what stays per-profile) + --isolated in the options table - profiles.md: 'From the dashboard' subsection + set-as-active vs switcher clarification - cli-commands.md: --isolated flag + profile-alias launch example * fix(dashboard): address profile-unification review findings Review findings (dev review on PR NousResearch#44007): 1. HIGH — stale page state on profile switch: pages load data on mount and didn't consume the profile scope, so a page opened under profile A kept showing A's state while writes silently targeted the newly selected B. Fixed structurally: ProfileKeyedRoutes wraps the routed page tree and keys it by the selected profile, remounting every page (fresh state + refetch) on switch. ChatPage keeps its own remount (channel keyed on scopedProfile). 2. HIGH — /api/model/auxiliary read was unscoped while /api/model/set wrote scoped (Models page could show default's aux pins while editing worker's). Endpoint now takes profile + _profile_scope, added to PROFILE_SCOPED_PREFIXES, HTTPException re-raise so ghost profiles 404 instead of 500. Regression test asserts read/write symmetry with differing worker/default aux config. 3. MEDIUM — tools post-setup spawned unscoped from the profile-aware drawer. Now spawns 'hermes -p <profile> tools post-setup <key>' (same mechanism as hub installs); drawer threads its profile prop. Most hooks install machine-level artifacts where the scope is inert, but hooks reading config/env now see the drawer's HERMES_HOME. 4. LOW — ty warnings: env Optional asserts before subscript/membership, fastapi import replaced with web_server.HTTPException re-use. 298 tests green across the four affected suites; tsc -b + vite build green; aux scoping E2E-verified with real imports. * fix(dashboard): address second profile-unification review (gille) 1. BLOCKER — profile scope dropped on sidebar navigation: ProfileProvider derived the selection from the current URL, and nav links are bare paths, so clicking Config from /skills?profile=worker silently reset the write target. State is now the source of truth; an effect re-asserts ?profile= onto the new location after every navigation (URL stays a synchronized projection for deep links/refresh), and an incoming URL param (e.g. 'Manage skills & tools' links) still wins. 2. BLOCKER — /api/model/options unscoped while model/set wrote scoped: the picker context (current model/provider, custom providers, per-profile .env auth state) now loads inside _profile_scope; added to PROFILE_SCOPED_PREFIXES. Test: a worker-only current-model pin appears in the scoped payload and not the unscoped one. 3. BLOCKER — MCP test-server probe escaped the scope after the config read: the probe now re-enters _profile_scope inside the worker thread so env-placeholder expansion resolves against the selected profile's .env. Known limit (documented): the probe's dedicated MCP event-loop thread doesn't inherit the contextvar (OAuth token paths). Test asserts get_hermes_home() inside the probe == the worker profile dir. 4. BLOCKER — broad excepts swallowed unknown-profile 404s: /api/model/info degraded to 200-with-empty-model-info and /api/mcp/catalog to a silently-empty catalog. Both re-raise HTTPException; 404 regression tests added for info/options/catalog. Polish: scope banner clears the fixed mobile header (mt-14 lg:mt-0); --open-profile hidden via argparse.SUPPRESS (internal re-exec flag); attach-path test now asserts the opened ?profile= URL. (Stale-page-state + /api/model/auxiliary findings from this review were already fixed in 92bcd15 — the review ran against e600f69.) 35 tests in the two new suites + 274 in the adjacent ones, all green; tsc -b + vite build green; scoping E2E-verified with real imports. * docs(dashboard)+fix: self-review pass — Profiles page section, REST profile-param tip, body-beats-query precedence Docs: - web-dashboard.md: add the missing 'Profiles' subsection to Pages (cards, create/builder, manage-skills jump, set-as-active vs switcher distinction, editors); REST API section gets a profile-scoped-endpoints tip documenting ?profile= / body profile / 404 semantics / /api/pty - (profiles.md + cli-commands.md were already updated in e600f69) Precedence fix: scoped endpoints taking BOTH a query param and a body field now resolve body.profile first. The SPA's fetchJSON injects the query param from the GLOBAL switcher; an explicit body.profile (e.g. Profile Builder flows writing into a specific new profile) is the more specific intent and must not be overridden by whatever the sidebar happens to be set to. Matches the documented 'explicit beats global' contract in api.ts. Verified: 304 tests green across the four suites; tsc -b + vite build green; docusaurus build green (only pre-existing broken-link warnings, none from this PR's pages). (cherry picked from commit 875aa8f)