fix(desktop): derive SSH lock/token/log paths from remote HERMES_HOME

[francois352]

Problem

Desktop's SSH remote lifecycle hardcodes ~/.hermes/desktop-ssh for its lock/token/log state (REMOTE_LOCK_DIR). When the remote host runs Hermes with a custom HERMES_HOME (e.g. /root/hermes-data), the Desktop uploads the one-time SSH session token under ~/.hermes/... while the backend expects its state under the custom home — so the backend rejects the token and the connection fails with an auth error on every attempt.

Fix

Derive the lock, token and log paths from the remote HERMES_HOME already returned by probeRemoteHermesHome(), threaded through as a parameter (no mutable global state). DEFAULT_REMOTE_HERMES_HOME = '~/.hermes' remains the fallback so behavior is unchanged for default-home remotes, and the probed value passes validateRemotePath before use.

Testing

• 64 focused tests in remote-lifecycle.test.ts pass (includes new cases for custom-home path derivation)
• tsc -p tsconfig.electron.json --noEmit clean
• eslint clean on both files
• Verified end-to-end against a real remote with HERMES_HOME=/root/hermes-data: token adopted (file removed after adoption), lock/log created under the custom home, backend spawned --isolated on loopback and correctly reused across Desktop reconnects

Notes for reviewers

• Pre-existing lockfiles under the old hardcoded path fail the logPath equality check and are treated as absent (clean respawn); they are not migrated or deleted.
• The helpers keep a default hermesHome parameter for the exported test surface; if you prefer, we can make it required on the internal call chain to prevent future call-sites silently regressing to ~/.hermes.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes Hermes Desktop’s SSH remote lifecycle by ensuring Desktop’s remote lock/token/log artifacts are created under the remote host’s actual HERMES_HOME, rather than a hardcoded ~/.hermes/desktop-ssh. This aligns Desktop’s upload/lock/log locations with where the remote Hermes backend expects to find its SSH session token and related state, avoiding repeated auth failures on remotes configured with a custom HERMES_HOME.

Changes:

• Derive the remote desktop-ssh lock/token/log root from the probed HERMES_HOME, and thread it through the lifecycle helpers instead of using a hardcoded directory.
• Validate the probed remote home path before using it.
• Add a unit test covering custom-home path derivation to prevent regressions.

Reviewed changes

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

File	Description
apps/desktop/electron/remote-lifecycle.ts	Derives lock/token/log paths from probed remote HERMES_HOME and threads it through lifecycle helpers.
apps/desktop/electron/remote-lifecycle.test.ts	Adds coverage ensuring custom remote HERMES_HOME is used for lock/token/log paths.

---

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

[teknium1]

Thanks for addressing the custom remote HERMES_HOME path mismatch. The path threading and explicit detached-process HERMES_HOME propagation address the verified backend validation contract in hermes_cli/main.py:9974-9978.

Problems

• apps/desktop/electron/remote-lifecycle.ts:333 rejects a pre-PR default-home lock whose persisted logPath is ~/.hermes/... when the probe returns the equivalent /home/<user>/.hermes. Because connect() receives null, it cannot call cleanupStale() before spawning and overwriting the ownership record. Current fixtures demonstrate both representations at remote-lifecycle.test.ts:44-45 and :507.

Suggested changes

• Accept or migrate that legacy default-home representation when it maps to the same probed lock root, preserving reuse or safe cleanup.
• Add a regression test for a legacy lock plus an absolute default-home probe result.

Automated hermes-sweeper review.

[teknium1]

A pre-PR default-home lock stores logPath as ~/.hermes/..., while the probe may return the equivalent /home/<user>/.hermes. This equality then rejects a live valid lock before connect() can reuse or clean it, causing a fresh backend to overwrite its record. Please accept or migrate the safe legacy default-home representation and cover that upgrade path.