fix(desktop): preserve HERMES_DASHBOARD_SESSION_TOKEN from parent process

[1RB]

Context

The previous docs recommended pinning HERMES_DASHBOARD_SESSION_TOKEN in ~/.hermes/.env for remote mode. The current docs switched to username/password auth (HERMES_DASHBOARD_BASIC_AUTH_*). Users who set up remote mode under the old docs still have a stale pinned token in .env.

The bug (legacy migration edge case)

When those users run hermes desktop (local mode), the Desktop app generates a fresh random HERMES_DASHBOARD_SESSION_TOKEN per boot and injects it into the child backend. Then python-dotenv loads ~/.hermes/.env with override=True, clobbering the valid parent-injected token with the stale pinned one. Auth mismatch → 401 on every API call → Desktop can't start until the stale token is manually removed.

New users following current docs won't hit this because they won't have a pinned session token in .env.

Why #38586 does not fix this in practice

PR #38586 gates the fix on os.environ.get("HERMES_DASHBOARD_TUI") == "1", but the Desktop app never sets HERMES_DASHBOARD_TUI. I grepped the entire codebase (apps/desktop/, hermes_cli/, all TS/JS/CJS) — the variable only exists in #38586's own test (monkeypatched) and patch. In real usage the condition is always false, so the 401 boot loop still happens for users with a stale pinned token.

This fix (workaround)

This PR captures the parent-injected token unconditionally before any dotenv or external-secret loading, and restores it at the end. It works, but it's a workaround — the real fix should be a config migration that strips the stale HERMES_DASHBOARD_SESSION_TOKEN from .env during update, following the exact pattern used for ANTHROPIC_TOKEN (version 8 → 9 migration in hermes_cli/config.py).

Why this isn't the ideal fix:

• .env with override=True is designed to win over stale shell exports. The deeper issue is that .env is being used for both user configuration AND legacy runtime session state.
• The ideal fix: bump _config_version to 27 and add a migration block if current_ver < 27: that detects HERMES_DASHBOARD_SESSION_TOKEN in .env and removes it, since remote mode now uses username/password auth and local mode auto-generates tokens per boot. This follows the established migration pattern (ANTHROPIC_TOKEN cleanup in migrate_config).

Copilot review addressed

• Single capture-before, single restore-after all loading (including _apply_external_secret_sources). No duplication, linear sequence.
• Restore runs after external secret sources, ensuring the parent-injected token wins even if Bitwarden or other sources have a conflicting value.

Recommendation

Close this PR in favor of a proper config migration (version 27 → strip HERMES_DASHBOARD_SESSION_TOKEN from .env if present, with a console message explaining the auth model changed). The migration approach matches the existing ANTHROPIC_TOKEN cleanup pattern and removes the root cause without adding permanent complexity to env_loader.py.

Fixes #38575.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR prevents python-dotenv loads from overwriting a session token injected into the environment (avoiding a 401 “boot loop” when ~/.hermes/.env contains a stale token).

Changes:

• Capture HERMES_DASHBOARD_SESSION_TOKEN before loading dotenv files.
• Restore the token after loading the user and project .env files.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[1RB]

Closing in favor of a proper config migration (version 27 → strip legacy HERMES_DASHBOARD_SESSION_TOKEN from .env) which follows the existing ANTHROPIC_TOKEN cleanup pattern.

[1RB]

Superseded by #39652. The runtime preservation approach in this PR was a workaround; the root fix is a config migration that strips the stale HERMES_DASHBOARD_SESSION_TOKEN from .env during hermes update (config version 27). This removes the legacy entry entirely rather than fighting python-dotenv override on every boot. Also fixes #38575 and supersedes #38586.