Summary

Pulled the branch and walked all four files. Two distinct fixes in here, both addressing the same symptom (profile-switch context loss on first turn) but at different layers: a path-aware reload in api/config.py, and a placeholder-retag at chat-start in api/routes.py. Both are scoped narrowly and the test coverage is solid. One question and one nit below.

Code reference

The get_config() change is the heart of this — previously it cached forever once _cfg_cache was non-empty:

def get_config() -> dict:
    """Return the cached config dict, loading from disk if needed."""
    if not _cfg_cache:
        reload_config()
    return _cfg_cache

Now it watches both the path and the mtime, and reloads when either changes — but only when there are no in-memory overrides:

config_path = _get_config_path()
try:
    current_mtime = config_path.stat().st_mtime
except OSError:
    current_mtime = 0.0
cache_stale = current_mtime != _cfg_mtime or _cfg_path != config_path
if not _cfg_cache or (cache_stale and not _cfg_has_in_memory_overrides()):
    reload_config()

(api/config.py:228-237.) _cfg_has_in_memory_overrides() compares a JSON fingerprint of the cache against the snapshot taken at the last successful disk load. That neatly preserves test-time monkeypatches and any legitimate runtime mutations of cfg (which is aliased to _cfg_cache at api/config.py:297).

Diagnosis

Reading the matching agent contract — _get_config_path() resolves to get_active_hermes_home() / "config.yaml" (api/config.py:189-199), and get_active_hermes_home() already reads _tls.profile per-thread (api/profiles.py:185-202, populated by server.py:127 and :145 from the cookie on every request). So the path was already correct per-request; the bug was only that the cached config was keyed solely on mtime and so two profiles with identical config.yaml mtimes could leak into each other. The path key in the cache invalidation closes that hole.

The chat-start retag on api/routes.py:5943-5961:

requested_profile = str(body.get("profile") or "").strip()
if requested_profile:
    try:
        from api.profiles import _PROFILE_ID_RE
        if requested_profile != "default" and not _PROFILE_ID_RE.fullmatch(requested_profile):
            return bad(handler, "invalid profile", 400)
    except ImportError:
        requested_profile = ""
if requested_profile and not _profiles_match(getattr(s, "profile", None), requested_profile):
    has_persisted_turns = bool(
        getattr(s, "messages", None)
        or getattr(s, "context_messages", None)
        or getattr(s, "pending_user_message", None)
    )
    if not has_persisted_turns:
        s.profile = requested_profile

The "empty session" check uses three predicates. messages/context_messages/pending_user_message are exactly the populated-on-first-turn fields; pending_user_message in particular is set by _prepare_chat_start_session_for_stream() at api/routes.py:5921, which runs after this retag. So a placeholder created before any chat_start has all three falsy and the retag fires; once chat_start lands once, pending_user_message (and post-stream messages) prevents a stale tag from being silently overwritten. Good.

One question

The _PROFILE_ID_RE import is wrapped in try/except ImportError, which silently disables validation when api.profiles fails to import. That is unreachable in practice (the same module is imported above by _profiles_match), so the fallback requested_profile = "" branch is dead code. Not blocking — just noting it would be a tiny bit cleaner to rely on from api.profiles import _PROFILE_ID_RE at the top of the function, given everything else here already depends on api.profiles being loadable.

Nit

static/messages.js:228 adds profile:S.activeProfile||S.session.profile||'default', but static/sessions.js:1875 (the optimistic-row builder) uses S.session.profile||S.activeProfile||'default' — the opposite priority. For a placeholder session created under profile A, S.session.profile is 'A' and S.activeProfile (the current cookie/header selection) is 'B'. The send path correctly prefers B so the retag will fire; the sidebar row will optimistically render as 'A' and only correct itself after the next session-list sync. This is a cosmetic blip, not a correctness issue, but worth a follow-up if it shows up in QA.

Verification

tests/test_profile_switch_1200.py:392-614 covers the four key paths: get_config reload on path change with identical mtime, retag of empty session, no-retag of non-empty session, and rejection of ../etc-style profile values. The os.utime setup pinning both files to the same mtime is exactly the failure mode the body describes. All three CI checks are green. Looks ready to merge.

Thanks @starship-s — this shipped in v0.51.8 (commit 85d0279) as part of a 7-PR full-sweep batch release. Stage rebased your branch onto current master, ran the full pre-release gate (4584 pytest, browser tests, Opus advisor verdict SHIP), and merged via release PR #1737.

GitHub didn't auto-close because the merge commit only references the squash-merged stage branch, not your fork's commit directly — closing manually for hygiene.

Live now on https://get-hermes.ai/ and on existing installs after git pull + restart.

Release notes: https://github.com/nesquena/hermes-webui/releases/tag/v0.51.8