fix(desktop): pin launch SessionDB handle to the launch home (#102526)

[HexLab98]

Summary

• Pin tui_gateway/server.py::_get_db() to the import-time launch home (Path(_hermes_home) / "state.db") instead of resolving through override-aware get_hermes_home() at first touch.
• Fixes #102526: the desktop multiplex cron ticker temporarily overrides HERMES_HOME per profile at startup, so the lazy launch SessionDB singleton could permanently bind to another profile's state.db — the default bot row then opened and wrote into the wrong profile's Bot Chat.
• Add a regression test for first-touch under a foreign override window, and adjust resume ownership leak filtering now that the shared launch handle carries an explicit path.

Test plan

• scripts/run_tests.sh tests/tui_gateway/test_launch_db_home_override_race.py tests/tui_gateway/test_session_resume_db_ownership.py -q (11 passed)
• Cold-start Hermes Desktop with multiple profiles; click the default Hermes bot first — Bot Chat should belong to the default profile, not another profile's session
• Confirm default backend holds its own state.db RW via lsof; replay session.list {profile: "default", title: "Bot Chat"} on the default backend WS and verify the default row is returned

[andrexibiza]

Blocking findings:

1. This freezes an ambient launch value; it does not establish launch-store authority. _hermes_home is captured from get_hermes_home() at module import, so this closes the later cron ContextVar race only when the child entered Python with the correct process home. The opposite realization failure is still open in #102315: a --profile default Desktop child can inherit a named profile's HERMES_HOME, in which case this patch deterministically pins the wrong physical state.db. #102343 is the current carrier, but this PR declares no dependency or composed acceptance test. The TUI store owner needs to be constructed from the resolved launch profile/root contract after child/profile realization and retain an immutable physical db_path/handle. Add a composed test for: foreign/profile-shaped child env → --profile default realization → foreign task-local override → first SessionDB touch → default physical store.

2. The implementation is already superseded by an unpatched decomposition path. This adds ownership logic to the current 18.5k-line tui_gateway/server.py, while #102117's current head (2776813df3b3f404611c633a9d1f3a087f337f8d) replaces this code and still has tui_gateway.server._get_db() call bare hermes_state_registry.acquire(). Merge #102534 first and #102117 second and the regression returns; reverse the order and the fix has no bounded destination. Land the launch-store owner in a focused post-decomposition TUI module, keep that owner under the 2,000-line boundary, make server.py delegate, and declare the merge-order/interlock with #102117.

3. The regression test proves only the one-line argument substitution, not the physical-store invariant or the remaining class. It replaces hermes_state.get_shared_session_db with a capture-only factory, so it never exercises the real path-keyed registry, opens either physical store, or audits the other ambient callers identified by #102526. Main still has eight files containing roughly fifteen no-path get_shared_session_db() calls across gateway/tools/MCP surfaces. #101719/#101740 demonstrates the opposite-direction failure when a named-profile agent rebuild rediscovers the launch singleton instead of carrying its existing store handle. Audit every no-path call reachable under override contexts and classify it explicitly: launch-owned paths obtain the immutable launch owner; profile/session-owned paths receive their exact path or live handle; no long-lived object discovers physical-store identity from ambient HERMES_HOME. Cover both first-touch orders plus cron startup, WS session RPCs, and in-place agent rebuilds.

Exact-head CI is green at ce9e5e2431ec7235268a0e73481069329116da51, but it does not exercise these authority/composition cases.

[andrexibiza]

Additive root-cause analysis — mechanism proven, trigger edge not yet closed

The durable root cause is a lifetime/authority mismatch: a process-lifetime persistence owner is constructed from task-local routing state.

For launch/default sessions, profile_home=None means “use the launch store,” and that path falls back to the lazy module-global _get_db(). Before this patch, _get_db() performed a no-path get_shared_session_db() acquisition, whose physical path was resolved through override-aware get_hermes_home() at acquisition time. Once assigned to _db, that transient answer became permanent authority for every later launch/default operation.

Confirmed causal mechanism:

1. a launch/default operation reaches the None -> _get_db() fallback;
2. the first _get_db() acquisition executes in a foreign profile context;
3. <foreign>/state.db is selected and cached in process-global _db;
4. later launch-backend session.list, session.resume, session.create, and agent persistence reuse that foreign handle;
5. stranded-session adoption and rebuild fallbacks amplify the split-brain rather than creating it.

The code therefore conflates three different identities:

• process/launch owner;
• request or task-local profile routing scope;
• session/persistence owner.

A ContextVar is valid for bounded routing. It is not valid evidence from which to mint a long-lived physical-store owner. The owner must be resolved once from an authoritative launch/profile realization and then carried as an immutable canonical path or live handle.

The reported poisoned handle is established; the stated cron-to-RPC transfer is not

The issue's live WS replay, message-count movement, and open-handle evidence establish that the launch backend was holding and writing the wrong physical store. The local post-fix readback also shows that removing call-time ambient resolution from this singleton is effective containment when _hermes_home is already correct.

The new test does not establish the claimed production trigger, however. set_hermes_home_override() writes a ContextVar; the Desktop ticker runs in a separate threading.Thread; WS dispatch runs through asyncio.to_thread, which carries the WS task's context. Mere temporal overlap between a cron override window and a WS request is insufficient to transfer the cron thread's context. Some concrete production call edge must invoke _get_db() from the foreign context itself, or schedule/copy that context into the callback that invokes it.

The regression manually installs a foreign override and directly calls _get_db() in that same context. That proves the singleton is susceptible, but it manufactures the missing edge rather than identifying it. Close the RCA by instrumenting and asserting the actual first-touch stack/thread/context during Desktop startup, then either:

• prove the exact cron/profile-scoped callback that initializes _db, directly or through a context-copied callback; or
• correct the trigger attribution if another profile-scoped path is the first toucher.

Patch boundary

Path(_hermes_home) / "state.db" removes call-time ContextVar dependence from this one singleton, but _hermes_home is still an import-time ambient value. #102315 establishes the opposite realization failure: a --profile default child can enter Python with a named profile's HERMES_HOME. In that state this patch does not recover authority; it deterministically freezes the wrong store. The complete repair must compose with #102343 and derive launch-store ownership only after CLI/profile realization.

The same invariant must survive decomposition. #102117 is now at 0b74043c1948df29ec620f369c62f3f9f76c295c, and its replacement TUI owner still performs a bare acquire(). Without an explicit interlock/bounded destination, the current fix is erased by the refactor.

Acceptance needs to establish the physical invariant, not just the factory argument:

• real launch and foreign SQLite stores, with row/readback and open-handle assertions;
• both first-touch orders;
• the actual Desktop ticker plus live WS session.list/create/resume, including the real first-touch edge;
• foreign/profile-shaped child env → --profile default realization → foreign task override → first DB touch → default physical store;
• session, in-place rebuild, and stranded-adoption handle continuity;
• fail closed when logical ownership and db.db_path disagree;
• the post-#102117 bounded owner.

Exact-head CI is green at ce9e5e2431ec7235268a0e73481069329116da51 for CI, Docker, and Nix. The preceding implementation commit a565ec910104d79284a9797edcbc496ab733f71e has no workflow run. Rewrite/squash implementation and regression into one substantive commit and run CI on that exact commit; do not add a proof-only receipt commit.

[andrexibiza]

Carrier lock — exactly one bounded repair for #102526

This PR is the single implementation carrier for the launch-SessionDB first-touch class. Do not open or preserve a parallel launch-store patch.

The current one-line/import-time pin is implementation input, not the final authority model. The composed repair must:

• resolve the launch profile/root after child/profile realization owned by [Bug]: Windows Desktop child can report --profile default while using another profile home/state.db #102315/fix(desktop): pin backend children to the Hermes-root HERMES_HOME #102343;
• construct and retain one immutable launch-store path or live handle;
• place that owner in a focused post-refactor: whole-codebase simplification — −34% source LOC, every god file decomposed, zero behavior change #102117 TUI module below 2,000 lines, with server.py delegating;
• prevent every long-lived owner from minting physical-store identity from task-local HERMES_HOME;
• classify every reachable no-path get_shared_session_db() call as launch-owned or profile/session-owned and pass the exact path/handle accordingly.

Acceptance must use real SQLite stores and prove both first-touch orders; foreign inherited env → --profile default realization → foreign task override → first DB touch; Desktop ticker plus WS list/create/resume; in-place rebuild and stranded-session adoption continuity; and fail-closed behavior when logical ownership disagrees with db_path.

#102534 does not land ahead of those composed edges, and #102117 must not erase the owner during decomposition. No second carrier. Every submitted commit must be exact-head green.

[thitar]

Second repro of #102526 (Linux/lyra, v0.21.0 — not macOS): same session id in TWO profile stores with diverging content

This is an independent confirmation of the HERMES_HOME binding race on a Linux host. A havoc-profile Bot Chat session exists in both the default ~/.hermes/state.db AND profiles/havoc/state.db, with different, diverging content — exactly the "backend writes into another profile's store" symptom.

Evidence (queried live from both stores, 2026-09-05)

Session 20260829_022741_9af00a (profile_name=havoc):

	profiles/havoc/state.db (correct store)	~/.hermes/state.db (default store — WRONG)
title	Bot Chat	Give me instructions to generate a key pair on… (message-derived)
source	tui	desktop
sessions-row message_count	368	184
actual messages in store	680	460
last_activity_at	18:05 (stuck)	22:22 (1 min before query — still being written)
hidden	1	0

Symptom observed

The havoc Bot Chat "dies" mid-conversation with no reload: the newest messages land in the default store's copy (desktop source, still advancing) while the Bots pane reads havoc's store (tui source, stuck at 18:05). Result: the conversation appears to lose its latest turns and the view goes stale/blank — though nothing is deleted. Older messages remain, latest vanish from view — matching "writes go to the store the view isn't reading."

Notes

• Gateway restarted fresh (pid 2565211, 19:57:44) post-update; source HEAD 9dd6634c5; desktop current. Not a stale-backend artifact.
• The default-store copy records profile_name=havoc — so the default backend is persisting a havoc-profile session into its own store.
• Happy to provide full message dumps / exact store paths / timestamps on request.

[teknium1]

Landed on main in #108074 (16e4496). Fix commit cherry-picked with authorship intact (test seam repaired against the current registry); thank you @HexLab98.