Agent can delete the Python interpreter Hermes's own runtime depends on, breaking startup

[hooraypublic]

Bug Description

A Hermes agent session can uninstall/delete the uv-managed Python interpreter that Hermes's own venv depends on, leaving the desktop app/gateway unable to start after reboot.

In this case, the user asked Hermes to install the newest stable Python >=3.13 and then remove older Python versions. Hermes used uv python install 3.14 successfully, then removed older uv-managed Python installs, including the base interpreter that the Hermes runtime venv pointed to. After reboot, Hermes failed to launch with:

Hermes couldn't start
The background gateway didn't come up.

[hermes] [boot] Using existing Hermes Python at <user-home>\AppData\Local\hermes\hermes-agent\venv\Scripts\python.exe
[hermes] [boot] Starting Hermes backend via existing Hermes Python ...
[hermes] Waiting for Hermes backend to launch
[hermes] error: uv trampoline failed to spawn Python child process
[hermes] Caused by: entity not found (os error 2)
[hermes] Hermes backend exited (1)

Root cause: the python.exe inside <user-home>\AppData\Local\hermes\hermes-agent\venv\Scripts\ was a uv trampoline. Its base interpreter, recorded by venv\pyvenv.cfg in the home = ... field, had been removed. The trampoline still existed, but its target no longer did.

Steps to Reproduce

On Windows with Hermes installed through the desktop/bootstrap flow:

1. Confirm Hermes uses a uv-created venv at:

   <user-home>\AppData\Local\hermes\hermes-agent\venv\
   

2. Check the base interpreter dependency:

   grep "^home" "$HOME/AppData/Local/hermes/hermes-agent/venv/pyvenv.cfg"

3. Install a newer Python with uv, for example:

   uv python install 3.14

4. Remove older uv-managed Python versions/directories, including the one referenced by the home = path.

5. Reboot or restart Hermes.

Expected Behavior

Hermes should not allow, or should strongly warn before allowing, an agent-executed operation that deletes the base Python interpreter used by Hermes's own active venv.

At minimum, before destructive Python operations such as:

uv python uninstall 3.11
rm -rf "$HOME/AppData/Roaming/uv/python/cpython-3.11..."

Hermes should check whether any target path/version is referenced by:

<user-home>\AppData\Local\hermes\hermes-agent\venv\pyvenv.cfg

and block or warn if it is.

Actual Behavior

The agent removed the interpreter without a dependency warning. Hermes then could not launch because its venv trampoline pointed to a missing base Python.

Environment

• OS: Windows 10

• Hermes surface: Desktop app / TUI recovery

• Python management: uv-managed Python installs

• Hermes runtime path:

  <user-home>\AppData\Local\hermes\hermes-agent\venv\Scripts\python.exe
  

• Error:

  uv trampoline failed to spawn Python child process
  Caused by: entity not found (os error 2)
  

Proposed Fix

Add a runtime self-dependency guard before agent-executed destructive Python operations. Possible approaches:

1. Parse Hermes's active venv pyvenv.cfg and record the home = base interpreter path.
2. When a terminal command attempts to uninstall/delete a Python version or a uv Python directory, compare the target against the active venv base path.
3. If the command would remove the base interpreter, require explicit user confirmation with a specific warning, or block unless a venv rebuild is performed first.
4. Consider a doctor check that warns if Hermes's venv base Python is missing or outside an expected managed location.

This should be a platform/runtime safety check rather than relying on the LLM to remember to inspect pyvenv.cfg.