fix(config): migrate stale HERMES_DASHBOARD_SESSION_TOKEN from .env (v30)

[1RB]

What does this PR do?

Automatically removes stale HERMES_DASHBOARD_SESSION_TOKEN from ~/.hermes/.env during config migration (version 30). The previous docs recommended pinning this token for remote mode; current docs use username/password auth. Users who set up remote mode under the old docs still have a stale pinned token that breaks Desktop LOCAL mode: the Desktop app generates a fresh random token per boot, then python-dotenv with override=True clobbers it with the stale pinned one, causing immediate 401 auth failures and a boot loop.

This fix removes the root cause (the legacy .env entry) rather than adding runtime workarounds to env_loader.py.

Related Issue

Fixes #38575

Supersedes #38586 (runtime token preservation approach gated on HERMES_DASHBOARD_TUI == "1", never set in production)

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/config.py:
  • Bumped _config_version 29 → 30
  • Added migration block if current_ver < 30: that unconditionally calls remove_env_value("HERMES_DASHBOARD_SESSION_TOKEN")
  • Uses remove_env_value() instead of save_env_value(key, "") to fully delete the key (not leave an empty string)
  • Emits warning on failure instead of silently swallowing exceptions

How to Test

1. Add HERMES_DASHBOARD_SESSION_TOKEN=*** to ~/.hermes/.env`
2. Run hermes update (or any command that triggers config migration)
3. Verify HERMES_DASHBOARD_SESSION_TOKEN is removed from .env
4. Verify hermes desktop (local mode) starts without 401 errors

Checklist

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(config):)
• I searched existing PRs — this is not a duplicate
• My PR contains only changes related to this fix
• I've added tests for my changes — no tests added (follows exact same pattern as existing ANTHROPIC_TOKEN migration which also has no dedicated tests; migration logic is implicitly exercised by every hermes update call)
• I've tested on my platform: Ubuntu 24.04
• N/A — no docs update needed (removes legacy behavior, not adds new)
• N/A — no config keys added/changed
• N/A — no architecture/workflow changes
• N/A — no tool behavior changes

[Copilot]

Pull request overview

Note

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

This PR bumps the Hermes CLI config schema version and adds a migration step to remove a now-obsolete dashboard session token from the user’s .env.

Changes:

• Bump _config_version from 26 to 27.
• Add a 26→27 migration that clears HERMES_DASHBOARD_SESSION_TOKEN in ~/.hermes/.env.

---

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[teknium1]

Thanks for tracing the stale-token failure mode and for addressing the earlier review feedback around full removal and diagnostics.

This is an automated hermes-sweeper review. Current main already satisfies the reported Desktop local-mode behavior through served-token reconciliation:

• apps/desktop/electron/main.ts:6918-6938 adopts the token served by the live local backend and uses it for the returned connection and WebSocket URL.
• apps/desktop/electron/dashboard-token.ts:88-101 intentionally accepts a token mismatch from a live spawned child, which covers dotenv overriding the spawn-time token.
• apps/desktop/electron/dashboard-token.test.ts:111-118 covers that live-child drift case.
• This behavior shipped in e96fe06e4968ebaf1c2df0a2a9c9fc9fc730b6cf and is contained in v2026.6.19.

Closing as implemented on main because the proposed migration is no longer needed to prevent the stated boot-loop/401 outcome.