[Bug]: `hermes uninstall` does not work on Windows

[dpurge]

Bug Description

I wanted to test hermes and installed it on Windows with iex (irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1)

Since it does not work with context window that I can fit onto my GPU with the model I like, and CPU is slow, I tried to delete it with hermes uninstall option 2 (Full uninstall - Remove everything including all data).

It has left a lot of stuff behind:

dir $env:LOCALAPPDATA/hermes

PS C:\> dir $env:LOCALAPPDATA/hermes

    Directory: C:\Users\...\AppData\Local\hermes

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           5/29/2026 12:55 AM                hermes-agent
d----           5/28/2026 10:27 PM                hooks
d----           5/28/2026 10:27 PM                image_cache
d----           5/28/2026 10:27 PM                logs
d----           5/29/2026 12:19 AM                memories
d----           5/28/2026 10:27 PM                pairing
d----           5/29/2026 12:26 AM                pastes
d----           5/28/2026 10:53 PM                sandboxes
d----           5/29/2026 12:17 AM                sessions
d----           5/29/2026 12:17 AM                skills
-a---           5/29/2026 12:18 AM        2132960 models_dev_cache.json
-a---           5/29/2026 12:18 AM            672 ollama_cloud_models_cache.json
-a---           5/29/2026 12:18 AM            298 provider_models_cache.json
-a---           5/28/2026 10:27 PM            536 SOUL.md
-a---           5/29/2026 12:28 AM         598016 state.db
-a---           5/29/2026 12:17 AM          32768 state.db-shm
-a---           5/29/2026 12:54 AM        2793392 state.db-wal

I would expect uninstall to work.

Steps to Reproduce

1. Install with iex (irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1) on Windows 11
2. Run
3. Uninstall with hermes uninstall option 2 (Full uninstall - Remove everything including all data)
4. Check for files that were NOT removed: dir $env:LOCALAPPDATA/hermes

Expected Behavior

All files created by hermes should be removed: additional tools installed, configuration, logs, everything

Actual Behavior

In my case 936 MB of useless files left in $env:LOCALAPPDATA/hermes
This includes memory and sessions that the user might believe to be removed.

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

CLI removed, cannot run `debug share`

Operating System

Windows 11

Python Version

It did NOT use my Python 3.12.8, I've seen a message that Python 3.11 was fetched with uv

Hermes Version

Too late - CLI removed

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[maxmilian]

Took a look at this — the report reproduces a real gap in the full-uninstall path. Posting a root-cause analysis and a few fix options before I open a PR, since the right direction has a trade-off I'd rather confirm with a maintainer first. (Note: I'm on macOS, so I can't directly reproduce the Windows file-locking behavior — flagging that up front.)

Root cause

The full-uninstall data removal in hermes_cli/uninstall.py is a single best-effort rmtree whose failure is swallowed:

# hermes_cli/uninstall.py  (step 5, full uninstall branch)
log_info("Removing configuration and data...")
try:
    if hermes_home.exists():
        shutil.rmtree(hermes_home)
        log_success(f"Removed {hermes_home}")
except Exception as e:
    log_warn(f"Could not fully remove {hermes_home}: {e}")
    log_info("You may need to manually remove it")

Two problems compound on Windows:

1. One locked file aborts the whole tree. state.db / state.db-wal / state.db-shm are SQLite WAL files. On Windows you can't delete a file while a handle is open, so if anything still holds the DB open, shutil.rmtree raises partway through and everything not yet visited survives — which matches the reporter's listing (sessions/, memories/, skills/, state.db*, ~936 MB left). There's no ignore_errors / onerror retry to recover.
2. The failure is invisible. The except only emits a log_warn, then the function still prints the ✓ Uninstall Complete! banner. A user who picked "Full uninstall — Remove everything including all data" is told it succeeded while memories/ and sessions/ remain on disk — a privacy concern, not just leftover bytes (the reporter calls this out).

On POSIX rmtree deletes open files fine, so this is effectively Windows-specific.

Fix options (and trade-offs)

#	Approach	Pro	Con
A	rmtree(hermes_home, onerror=<handler>) that clears read-only attr (os.chmod) and retries on PermissionError with a short backoff, then report any survivors instead of printing "Complete!"	Robust, no process model assumptions, self-contained	Retry won't help if a live process still holds the handle
B	Ensure no Hermes process holds the DB before removal — close the local SQLite connection in-process and psutil-kill any lingering agent/gateway PIDs (extends the existing uninstall_gateway step)	Removes the actual lock cause	Bigger blast radius; needs to find every handle owner; harder to get right cross-platform
C	Minimal honesty fix only: don't swallow → after rmtree, re-scan hermes_home and if non-empty, print exactly what remains + the manual-removal path; drop the false "Complete!" banner	Tiny, safe, no Windows repro needed to verify	Doesn't actually delete the leftovers
D	A + C combined: retry-aware rmtree, then verify-and-report whatever still survives	Best UX + best effort deletion	Slightly more code

My instinct is D (retry handler + truthful post-removal verification) since it both improves deletion and never lies about the result, while staying inside uninstall.py with no new process-management assumptions. But if you'd rather attack the lock at its source (B), or keep the change minimal (C), I'll follow your preference.

One open question for the repro: at the point hermes uninstall runs step 5, is the lock expected to come from the uninstall process itself (does it open state.db earlier in the run?) or only from a separate lingering process? That determines whether B is even necessary on top of A.

Happy to open the PR once you point at a direction.

[GottZ]

This was generated by AI during triage.

Summary

Two PRs reference #34185: #34364 directly fixes the reported full-uninstall failure by making Hermes-home removal resilient to transient locks and read-only files, while #50455 targets Windows command wrappers outside the reported leftover data tree and is already covered by the supported installer/uninstaller paths on main.

Related pull requests

• fix(uninstall): robust rmtree with retries fixes Windows leftover files (#34185) #34364 best fix — (+373/-6) — fixes: Replaces the single best-effort rmtree that aborted on the first Windows file error with chmod-assisted retries, leftover detection, actionable cleanup output, and regression coverage through the real full-uninstall caller. The keep_open review on fix(uninstall): robust rmtree with retries fixes Windows leftover files (#34185) #34364 requested a caller-level test; the subsequent diff adds that test and verifies robust removal routing plus leftover and remediation output.
• fix(tools): remove .cmd/.exe wrappers during Windows uninstall (#34185) #50455 [closed] unrelated — (+23/-4) — unrelated: Adds deletion of ~/.local/bin/hermes.cmd and hermes.exe, but those paths are not created by the official Windows installer and do not address the reported failure to remove $LOCALAPPDATA/hermes after a locked-file rmtree abort. This closed PR remains relevant as a ruled-out alternative: supported wrapper cleanup is already implemented on main, and its unconditional path-based deletion could remove unrelated files.

Suggested consolidation

Merge #34364 because it fixes the demonstrated #34185 root cause and now includes the caller-level regression coverage requested by review. Keep #50455 closed as already implemented/out of scope rather than treating it as a duplicate; no PR needs duplicate closure.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I34185(["issue #34185 (open)"])
    P34364["PR #34364 (open)"]
    P34364 -->|best fix| I34185
    class I34185 open
    class I34185 target
    class P34364 open
    class P34364 best
    click I34185 "https://github.com/NousResearch/hermes-agent/issues/34185"
    click P34364 "https://github.com/NousResearch/hermes-agent/pull/34364"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 2 pull requests and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 19 kB of PR diffs, 7 kB of issue/PR text, 8 kB of discussion (6 comments), 3 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.