Sessions no longer bind to or read another profile's state.db (#102526, #106761, #105887, #106974; salvage #102534, #106975)

[teknium1]

Sessions no longer bind to, read from, or point recovery at another profile's state.db: the Desktop launch backend pins its shared handle to its launch home, session_search refuses a bare-id read of a foreign profile's store, corruption guidance names the failing session's own database, and profile delete closes this process's shared SessionDB handles before rmtree.

What changed

• Launch handle races into a foreign profile's override window (Desktop: launch backend's session store binds to another profile's state.db via HERMES_HOME override race (default bot opens wrong profile's chat) #102526, Bug: Desktop/Dashboard default sessions can persist into another profile's state.db via cached SessionDB #59566) — tui_gateway/server.py::_get_db() called acquire() with no path, so its first touch resolved get_hermes_home() under whatever context-local HERMES_HOME override the desktop multiplex cron ticker had installed at that instant. The process-lifetime "own store" handle then pointed at another profile's state.db forever. Pinned to Path(_hermes_home) / "state.db" (import-time launch home). Salvaged from fix(desktop): pin launch SessionDB handle to the launch home (#102526) #102534 (@HexLab98); its test's seam was stale on main, so the test now opens a real registry handle and asserts the foreign home stays untouched.
• session_search(session_id=<bare id>) scanned every profile's state.db (session_search: reading a session by bare ID silently scans every profile's state.db and returns another profile's full transcript #106761, refs security: session_search tool has no chat/profile ownership scoping (cross-chat and cross-profile transcript leak) #87779) — a miss in the caller's store fell through to _locate_session_db(), which opened each profile's DB read-only and returned the first owner's full transcript with no profile named. Profiles are isolated islands; the scan is removed. A miss stays a miss with a hint to pass profile= / @session:<profile>/<id> (the explicit cross-profile read is unchanged). The existing test that pinned the leak is inverted; the schema eval runner no longer fakes the scan.
• Corrupt-session recovery guidance targeted the process default DB (Corrupt-session recovery guidance can target the wrong profile database #105887) — the explainer filled {db_path} from _default_db_path(); a Desktop serve backend hosting named-profile sessions told the operator to inspect/repair the root database. The turn finalizer now passes the agent's own _session_db.db_path.
• Profile delete left state.db open in-process → WinError 32 (Profile delete still hits WinError 32 on state.db #106974) — delete_profile() released holographic memory-store handles but not shared hermes_state_registry SessionDB handles. New close_all_under(directory) force-closes every generation under the doomed dir and waits for already-admitted teardown barriers (a final release() can drop the generation before the physical close finishes). Salvaged from fix(cli): release SessionDB handles when deleting a profile #106975 (@Sora-bluesky), both commits. Cannot run on Windows here; host-independent invariant tests cover "handle closed, sibling untouched, sweep waits for in-flight close".

Live repro (real SQLite, temp HERMES_HOME, hermes_state* purged from sys.modules)

Item	Before (origin/main)	After
#102526 launch _get_db() first-touch under foreign override	bound to …/foreign/state.db	bound to …/launch/state.db; foreign file never created
#106761 bare-id read from default of a victim session	success=True profile=victim message_count=1 (full transcript)	success=False, error hints profile=; named profile="victim" read still works
#105887 corrupt guidance for a profiles/research session	--source <root>/state.db	--source <root>/profiles/research/state.db
#106974 delete_profile with a registry handle open	handle stays open (_conn not None)	_conn is None, same-name recreate acquires a fresh handle

Regression tests are red with each fix reverted (verified for the launch pin by reverting the one-line change).

Assessed, not changed here

• [Bug]: Desktop SSH spawn omits HERMES_HOME for --profile — Linux child freezes DEFAULT_DB_PATH to shared root state.db #103467 (Linux Desktop SSH spawn omits HERMES_HOME) — premise does not hold on main: hermes_cli.main runs _apply_profile_override() at import (before hermes_state is imported; verified hermes_state not in sys.modules after import hermes_cli.main), so --profile alpha serve --isolated with no HERMES_HOME yields DEFAULT_DB_PATH=<root>/profiles/alpha/state.db on both main and the v0.21.0 tag. fix(desktop): pass HERMES_HOME for named-profile SSH serves so DB isolation holds (#103467) #103480 (@PRATHAMESH75) adds an env export that is redundant with --profile; not salvaged.
• [Bug]: Windows Desktop child can report --profile default while using another profile home/state.db #102315 (Windows child --profile default inherits another profile's home) — resolve_profile_env("default") already strips a profile-shaped HERMES_HOME to its root (57d94dd8dc8, present at the reporter's SHA); verified HERMES_HOME=<root>/profiles/work + --profile default → <root>/state.db. The reporter's observed HERMES_HOME=…/profiles/work in the default child's environment is a spawn-env cosmetic on Windows (case-insensitive key), not a store-binding bug on current main. fix(desktop): pin backend children to the Hermes-root HERMES_HOME #102343 (@686f6c61) is a reasonable hygiene change for the env block but not a store fix; left for a Desktop lane.
• Desktop: stale active-profile.json is never rewritten on profile switch — app relaunch reopens wrong profile; typed messages land in another profile's DB #107528 (stale active-profile.json) — rail switches call profile.remember only for local primary-backend activations by design ([Bug]: Desktop profile rail forgets the selected workspace after restart #79886); the store-binding symptom described is the Desktop: launch backend's session store binds to another profile's state.db via HERMES_HOME override race (default bot opens wrong profile's chat) #102526 class fixed here. The pointer-staleness policy is a Desktop UX call, not touched.
• ModuleNotFoundError: No module named 'hermes_state_registry' (editable/git install, 0.21.0 and current main) #101884 / Nix sealed venv missing hermes_state_holders / hermes_state_registry (py-modules omission) #102632 (hermes_state_* missing from py-modules) — already fixed on main by 283c4f058c5 (setup.py::_root_py_modules() derives the list from the tree; tests/test_packaging_py_modules.py is the contract test that fails if packaged code imports an unshipped root module). fix(managed_uv): add missing hermes_state_* modules to py-modules for replacement env smoke tests #74506 is superseded.
• fix(tui): keep in-session agent rebuilds on their own profile store #104143 (@HexLab98, in-session rebuild profile store) is already on main as 8da23bdae4f. fix(state): close the profile-mode HOME hole in the live state.db guard #101995 and fix(sessiondb): resolve default path from current Hermes home #94004 target other clusters (live-DB guard roots / default-path plumbing) and are not part of this PR.

Fixes #102526
Fixes #106761
Fixes #105887
Fixes #106974
Refs #59566, #87779, #103467, #102315, #107528, #101884, #102632

Salvaged with authorship: #102534 (@HexLab98), #106975 (@Sora-bluesky).

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 0a98e28 — fix(agent): corrupt-session recovery guidance names the sess}

⚠️ Warnings

OSV vulnerability scan · View job

80 known vulnerabilities found in pinned dependencies.

• CVE-2026-83608 in package-lock.json
• CVE-2026-83608 in package-lock.json
• CVE-2026-84375 in package-lock.json
• CVE-2026-84375 in website/package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-85062 in package-lock.json
• CVE-2026-85062 in website/package-lock.json
• CVE-2026-83609 in package-lock.json
• CVE-2026-82417 in scripts/whatsapp-bridge/package-lock.json
• CVE-2026-82417 in website/package-lock.json
• CVE-2026-84369 in website/package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-75931 in package-lock.json
• CVE-2026-75931 in website/package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 5m41s vs 6m20s (-10.3%). 5 job(s) slower, 9 faster,

• Python lints / ruff enforcement (blocking): -105.0s
• Python lints / Windows footguns (blocking): +55.0s
• OS-specific tests / Windows-only tests: -41.0s
• OSV scan / Scan lockfiles / osv-scan: -36.0s
• Python tests / Run tests: -28.0s