Regression in v2026.7.7.x: hermes -p <profile> chat runs the default profile (session store, SOUL, model config all default)

[marknisk]

On v2026.7.1 (0.18.0), hermes -p home-ops chat correctly scoped the whole
session to the profile: session persisted in the profile's state.db, SOUL
loaded from the profile home, turns logged under the profile's logs.

On v2026.7.7.2 (0.18.2, same deployment upgraded, Docker image, upstream
9de9c25f), the SAME invocation runs the DEFAULT profile:

• session row appears in the DEFAULT state.db with the stock
  You are Hermes Agent… system prompt (profile SOUL.md exists and loads
  fine when tested directly via load_soul_md),
• turn_context logs to the default profile's agent.log,
• provider resolution differs from the profile's config (our default-scoped
  turns picked the custom fallback provider instead of the configured
  openai-codex).

Reproduce:

hermes -p <secondary-profile> chat        # or chat --cli
# ask "who are you?" → stock identity; session lands in default state.db

Two data points that narrow it:

• hermes -p <profile> prompt-size scopes CORRECTLY on 0.18.2 (writes the
  profile's log/caches, builds the profile SOUL into the prompt) — so the
  -p argv bootstrap in hermes_cli/main.py still works; the loss happens
  somewhere in the chat/TUI init path.
• Workaround: bypass the flag with the env var —
  HERMES_HOME=<profiles-dir>/<name> hermes chat scopes correctly
  (verified: session lands in the profile state.db with the profile SOUL
  as system prompt).

Gateway-side lanes (/p/<profile>/ dashboard) are unaffected.

[teknium1]

Closing as not reproducible. We verified this three separate ways and could not trigger it — including a real python -m hermes_cli.main -p <profile> chat --cli at the exact reported version (v2026.7.7.2, upstream 9de9c25) against clean temp HOMEs in BOTH layouts (standard ~/.hermes/profiles/ and Docker-style HERMES_HOME=/opt/data). In every run the session row landed in the profile's state.db with the profile's SOUL and model config; the default state.db was never created. The only change to the profile-override path between v2026.7.1 and v2026.7.7.2 is an unrelated argv-parsing addition (--usage-file).

Since your workaround (HERMES_HOME= hermes chat) works, and -p uses the identical mechanism, the scoping loss is most likely environmental — e.g. a wrapper script/alias consuming the -p flag, a sticky /active_profile file, or the s6 supervised-child path in the container.

If you can still reproduce it, please open a new issue with:

1. The exact invocation (including any wrapper script, alias, or docker exec line)
2. env | grep HERMES from inside the process environment at launch
3. Contents of <hermes-root>/active_profile if it exists
4. Whether this is the s6-supervised container gateway or a manual shell
5. The first ~20 lines of the profile's agent.log from a fresh launch

With a reproducible recipe we'll pick it straight back up — the session-store misroute would be a serious bug if confirmed.

[marknisk]

Confirming from the reporting deployment: we can no longer reproduce this either. Re-ran the exact original invocation today (docker exec -u 10000 <container> hermes -p home-ops chat, same image, v2026.7.7.2 / upstream 9de9c25, no HERMES_HOME override, container env still carries a global HERMES_HOME=/opt/data): the session row landed in the profile's state.db with the full profile SOUL as system prompt and the profile's model/provider config; the default store was untouched.

The misroute was real when reported (we verified the session row in the default state.db with the stock prompt at the time), but the deployment has been through many restarts and auth-store operations since, and whatever stale state caused it is gone. Your active_profile hypothesis is plausible but unverifiable retroactively — no such file exists now and we didn't check for it then.

No reopen needed — closure corroborated. Thanks for the thorough triage and the reopen checklist; it's what let us settle this quickly.