fix(linux): resolve venv symlink chain when generating desktop entry

[aardbij26-ship-it]

Problem

On Linux installs using a uv-managed venv, the generated desktop entry has a non-runnable Exec line, so launching Hermes from the dock/menu icon silently fails. Fixes #90292.

Root cause

uv venvs chain their interpreter symlinks: venv/bin/python3 -> python -> uv-managed python. _needs_interpreter() compared the shebang path against sys.executable's directory as raw strings, so the uv-managed interpreter was not recognized as the running interpreter and got prefixed explicitly:

Exec=/home/user/.local/share/uv/python/cpython-3.11.15-linux-x86_64-gnu/bin/python3.11 /home/user/.hermes/hermes-agent/venv/bin/hermes desktop

That interpreter runs without venv activation and dies on ModuleNotFoundError: No module named 'hermes_cli' — silently, since Terminal=false.

Fix

Compare resolved paths instead of raw strings, so the venv symlink chain is recognized as the running interpreter and the entry stays a plain hermes desktop launch.

Test

Adds test_exec_leaves_symlinked_venv_shebang_alone covering the uv-venv symlink chain case. Full suite: 16 passed, 2 skipped.

[SemihMutlu07]

Fresh confirmation — this fix resolves the exact scenario reported here.

Environment

Arch Linux, git install, Hermes Agent v0.20.6, uv-managed venv at ~/.hermes/hermes-agent/venv where venv/bin/python is a symlink to ~/.local/share/uv/python/cpython-3.11.16-linux-x86_64-gnu/bin/python3.11.

How it manifested

hermes desktop wrote the desktop entry with a non-runnable Exec:

Exec=/home/<user>/.local/share/uv/python/cpython-3.11.16-linux-x86_64-gnu/bin/python3.11 /home/<user>/.hermes/hermes-agent/venv/bin/hermes desktop

That bare interpreter has none of the venv's site-packages (e.g. OpenAI SDK: Not installed vs 2.24.0 in the venv), so every launcher click died silently — invisible because Terminal=false. Meanwhile hermes desktop from a login shell worked, so the app looked "installed but unlaunchable from the menu."

Root cause

Matches this PR: Path(sys.executable).resolve() follows uv's venv/bin/python → <base interpreter> symlink, escaping the venv, so the venv shebang was mis-flagged as "escaping" and the dead interpreter got prefixed onto Exec.

Verification

Applying exactly this approach (compare resolved paths so the venv symlink chain is recognized as the running interpreter) makes resolve_exec_command() produce a plain venv launch:

Exec=/home/<user>/.hermes/hermes-agent/venv/bin/hermes desktop

With that entry:

• The module test suite passes (15 passed, 2 skipped).
• gtk-launch hermes (the exact app-menu click path) exits 0 and brings up the Electron app; an already-running instance hands off to the single instance rather than duplicating.

This also matches the approach noted in #94051 / the second comment on #90292 (keep the venv symlink intact). Happy to test candidate branches on this machine (Arch + uv venv symlink).