fix(desktop): don't follow venv python symlink in Linux .desktop Exec

[flowersjus]

Bug Description

After hermes desktop rebuilds the Linux menu entry, launching Hermes from the app menu does nothing. A TTY hermes desktop works (including after the chrome-sandbox sudo).

The generated ~/.local/share/applications/hermes.desktop contained:

Exec=/usr/bin/python3.11 /home/…/.hermes/hermes-agent/venv/bin/hermes desktop

That command exits 1 with ModuleNotFoundError: hermes_cli. Terminal=false, so there is no window and no error.

Follow-up to #90292 (still open). That fix prefixed sys.executable, but .resolve() followed the venv python symlink back out to the system interpreter.

Root Cause

A venv's bin/python3 is typically a symlink to /usr/bin/python3.11. Invoking the system path does not activate the venv — sys.prefix stays /usr, so hermes_cli is missing.

resolve_exec_command() wrote Path(sys.executable).resolve() into Exec=. After a successful TTY launch (which does use the venv shebang), the rewritten menu entry pointed at system Python.

A second hole in the same helper: _needs_interpreter used exe_dir not in shebang. When the running interpreter lives under /usr/bin, that substring matches #!/usr/bin/env python3 and skips the #90292 prefix.

Fix

• _running_interpreter() returns Path(sys.executable) without following the venv→system symlink, and that path is what gets written into Exec= when a prefix is needed.
• Console scripts whose shebang already names a python next to themselves (venv/bin/hermes → venv/bin/python3) are left alone.
• #!/usr/bin/env python3 always gets the prefix (no more /usr/bin ⊂ /usr/bin/env false negative).

How to Verify

1. On Linux with a venv whose bin/python3 is a symlink to /usr/bin/python3.X, run hermes desktop once from a TTY.
2. awk -F= '/^Exec=/{print substr($0,6)}' ~/.local/share/applications/hermes.desktop
   • bad: starts with /usr/bin/python3.11
   • good: ~/.local/bin/hermes desktop or …/venv/bin/hermes desktop (or …/venv/bin/python3 … if prefixed)
3. Click the menu icon — window should open.
4. Reproduce the silent fail of the old line:
   /usr/bin/python3.11 ~/.hermes/hermes-agent/venv/bin/hermes --version → ModuleNotFoundError: hermes_cli

Test Plan

• Added regression test (test_exec_does_not_follow_venv_python_symlink)
• Existing tests/hermes_cli/test_linux_desktop_entry.py still pass (16 passed, 2 skipped)
• Manual verification: rewrote the live .desktop Exec and confirmed --version works; the old Exec line fails as above

Risk Assessment

Low — Linux .desktop writer only. macOS/Windows installers are no-ops here. Worst case a prefixed Exec uses the unresolved venv interpreter (correct) instead of the resolved system one (broken).

[alt-glitch]

This was generated by AI during triage.

Duplicate of #92090: both preserve the unresolved venv interpreter in the generated Linux desktop Exec= entry so the launcher does not fall back to system Python.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

This is the more complete of the two open fixes for the venv-symlink .desktop bug (the other, #92285, drops only .resolve()). Beyond the core fix, two adjacent edge cases in _needs_interpreter are genuinely load-bearing:

• The /usr/bin/env shebang trap: exe_dir not in shebang substring-matching previously treated a script whose shebang is #!/usr/bin/env python3 as "already inside the venv" because /usr/bin is a substring of /usr/bin/env — the explicit env branch fixes a real silent-death path, and the comment explains it precisely.
• Console scripts sitting next to their own interpreter (venv/bin/hermes → venv/bin/python3) are correctly recognized as self-sufficient rather than re-prefixed.

Comparing against the unresolved sys.executable in exe_dir is what makes the whole function coherent under symlinked venvs. Tests cover the new branches at the right level.

Two suggestions:

1. _running_interpreter() currently returns Path(sys.executable) with the docstring carrying all the weight ("Do not resolve()"). Since the failure mode is one stray .resolve() call away, consider enforcing rather than documenting: e.g. an os.path.abspath-based construction plus a comment, or a test asserting the Exec line never contains the resolved system interpreter when running under a simulated symlinked venv (the test file already fakes sys.executable, so this looks cheap).

2. Same note as on fix(desktop): preserve venv symlink in .desktop Exec line #92285: consolidation — whichever PR lands should absorb the other's evidence; yours has the deeper root-cause write-up.