mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-10 08:32:09 +00:00
docs(windows): correct native data dir to %LOCALAPPDATA%\hermes (#42856)
* docs(windows): correct native data dir to %LOCALAPPDATA%\hermes The Windows-native guide claimed a deliberate split where config, auth, skills, and sessions live under %USERPROFILE%\.hermes. That is not what the installer does: scripts/install.ps1 sets HERMES_HOME=%LOCALAPPDATA%\hermes, so data actually lives in %LOCALAPPDATA%\hermes alongside the disposable install (the hermes-agent\, git\, node\, bin\ subdirectories) — `hermes config` confirms config.yaml/.env resolve there, not under %USERPROFILE%. Update the data-layout table, the "split is deliberate" note, the env-var and uninstall sections to describe the real layout: data and install share the %LOCALAPPDATA%\hermes root, reinstall only replaces hermes-agent\, and a full wipe targets %LOCALAPPDATA%\hermes (with %USERPROFILE%\.hermes kept only as a legacy/WSL cleanup). Mention HERMES_HOME as the override knob. * docs(windows): fix PATH + bin layout to match installer The installer adds hermes-agent\venv\Scripts (where hermes.exe lives) to User PATH and sets HERMES_HOME — not %LOCALAPPDATA%\hermes\bin. The \bin dir holds Hermes's managed uv.exe, not a hermes.cmd shim. Correct the install-step list and the data-layout table accordingly. * fix(install): show real HERMES_HOME path in setup messages The native Windows installer wrote config/env/skills under $HermesHome (%LOCALAPPDATA%\hermes) but its success messages claimed ~/.hermes, which doesn't exist on native Windows. Print the actual paths so a new user can find their config, .env, and skills.
This commit is contained in:
xxxigm
GitHub
parent
8d71c38919
commit
02f878ec5a
2 changed files with 23 additions and 22 deletions
|
|
@ -1725,7 +1725,7 @@ function Write-BootstrapMarker {
|
|||
function Copy-ConfigTemplates {
|
||||
Write-Info "Setting up configuration files..."
|
||||
|
||||
# Create ~/.hermes directory structure
|
||||
# Create the HERMES_HOME directory structure ($HermesHome, default %LOCALAPPDATA%\hermes)
|
||||
New-Item -ItemType Directory -Force -Path "$HermesHome\cron" | Out-Null
|
||||
New-Item -ItemType Directory -Force -Path "$HermesHome\sessions" | Out-Null
|
||||
New-Item -ItemType Directory -Force -Path "$HermesHome\logs" | Out-Null
|
||||
|
|
@ -1743,13 +1743,13 @@ function Copy-ConfigTemplates {
|
|||
$examplePath = "$InstallDir\.env.example"
|
||||
if (Test-Path $examplePath) {
|
||||
Copy-Item $examplePath $envPath
|
||||
Write-Success "Created ~/.hermes/.env from template"
|
||||
Write-Success "Created $envPath from template"
|
||||
} else {
|
||||
New-Item -ItemType File -Force -Path $envPath | Out-Null
|
||||
Write-Success "Created ~/.hermes/.env"
|
||||
Write-Success "Created $envPath"
|
||||
}
|
||||
} else {
|
||||
Write-Info "~/.hermes/.env already exists, keeping it"
|
||||
Write-Info "$envPath already exists, keeping it"
|
||||
}
|
||||
|
||||
# Create config.yaml
|
||||
|
|
@ -1758,10 +1758,10 @@ function Copy-ConfigTemplates {
|
|||
$examplePath = "$InstallDir\cli-config.yaml.example"
|
||||
if (Test-Path $examplePath) {
|
||||
Copy-Item $examplePath $configPath
|
||||
Write-Success "Created ~/.hermes/config.yaml from template"
|
||||
Write-Success "Created $configPath from template"
|
||||
}
|
||||
} else {
|
||||
Write-Info "~/.hermes/config.yaml already exists, keeping it"
|
||||
Write-Info "$configPath already exists, keeping it"
|
||||
}
|
||||
|
||||
# Create SOUL.md if it doesn't exist (global persona file).
|
||||
|
|
@ -1794,25 +1794,25 @@ Delete the contents (or this file) to use the default personality.
|
|||
"@
|
||||
$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
|
||||
[System.IO.File]::WriteAllText($soulPath, $soulContent, $utf8NoBom)
|
||||
Write-Success "Created ~/.hermes/SOUL.md (edit to customize personality)"
|
||||
Write-Success "Created $soulPath (edit to customize personality)"
|
||||
}
|
||||
|
||||
Write-Success "Configuration directory ready: ~/.hermes/"
|
||||
Write-Success "Configuration directory ready: $HermesHome"
|
||||
|
||||
# Seed bundled skills into ~/.hermes/skills/ (manifest-based, one-time per skill)
|
||||
Write-Info "Syncing bundled skills to ~/.hermes/skills/ ..."
|
||||
# Seed bundled skills into $HermesHome\skills (manifest-based, one-time per skill)
|
||||
Write-Info "Syncing bundled skills to $HermesHome\skills ..."
|
||||
$pythonExe = "$InstallDir\venv\Scripts\python.exe"
|
||||
if (Test-Path $pythonExe) {
|
||||
try {
|
||||
& $pythonExe "$InstallDir\tools\skills_sync.py" 2>$null
|
||||
Write-Success "Skills synced to ~/.hermes/skills/"
|
||||
Write-Success "Skills synced to $HermesHome\skills"
|
||||
} catch {
|
||||
# Fallback: simple directory copy
|
||||
$bundledSkills = "$InstallDir\skills"
|
||||
$userSkills = "$HermesHome\skills"
|
||||
if ((Test-Path $bundledSkills) -and -not (Get-ChildItem $userSkills -Exclude '.bundled_manifest' -ErrorAction SilentlyContinue)) {
|
||||
Copy-Item -Path "$bundledSkills\*" -Destination $userSkills -Recurse -Force -ErrorAction SilentlyContinue
|
||||
Write-Success "Skills copied to ~/.hermes/skills/"
|
||||
Write-Success "Skills copied to $HermesHome\skills"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ The installer auto-retries flaky git fetches and strips BOM from any downloaded
|
|||
|
||||
### Desktop installer (alternative)
|
||||
|
||||
A thin GUI installer is also available — useful if you'd rather double-click an `.exe` than open PowerShell. Download Hermes Desktop, run the installer, and on first launch the GUI calls `install.ps1` under the hood to provision Python (via `uv`), Node, PortableGit, and the rest of the dependency bootstrap described below. After the first run, the desktop app and the PowerShell-installed `hermes` CLI share the same `%LOCALAPPDATA%\hermes\hermes-agent` install and `%USERPROFILE%\.hermes` data directory — switch between the GUI and the CLI freely.
|
||||
A thin GUI installer is also available — useful if you'd rather double-click an `.exe` than open PowerShell. Download Hermes Desktop, run the installer, and on first launch the GUI calls `install.ps1` under the hood to provision Python (via `uv`), Node, PortableGit, and the rest of the dependency bootstrap described below. After the first run, the desktop app and the PowerShell-installed `hermes` CLI share the same `%LOCALAPPDATA%\hermes\hermes-agent` install and `%LOCALAPPDATA%\hermes` data directory — switch between the GUI and the CLI freely.
|
||||
|
||||
Use the desktop installer when you want a familiar Windows install experience or you're handing Hermes to a non-developer; use the PowerShell one-liner when you're already in a terminal.
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Top-to-bottom, in order:
|
|||
6. **Tiered `uv pip install`** — tries `.[all]` first, falls back to progressively smaller sets (`[messaging,dashboard,ext]` → `[messaging]` → `.`) if a `git+https` dep flakes on rate-limited GitHub. Prevents "single flake drops you to a bare install" failure mode.
|
||||
7. **Auto-installs messaging SDKs** keyed off `.env` — if `TELEGRAM_BOT_TOKEN` / `DISCORD_BOT_TOKEN` / `SLACK_BOT_TOKEN` / `SLACK_APP_TOKEN` / `WHATSAPP_ENABLED` are present, runs `python -m ensurepip --upgrade` and targeted `pip install` calls so each platform's SDK is actually importable.
|
||||
8. **Sets `HERMES_GIT_BASH_PATH`** to the resolved `bash.exe` so Hermes finds it deterministically in fresh shells.
|
||||
9. **Adds `%LOCALAPPDATA%\hermes\bin` to User PATH** — exposes the `hermes` command after you open a new terminal.
|
||||
9. **Adds `%LOCALAPPDATA%\hermes\hermes-agent\venv\Scripts` to User PATH and sets `HERMES_HOME=%LOCALAPPDATA%\hermes`** — exposes the `hermes` command (and points it at your data dir) after you open a new terminal.
|
||||
10. **Runs `hermes setup`** — the normal first-run wizard (model, provider, toolsets). Skip with `-SkipSetup`.
|
||||
|
||||
:::tip Skip provider hunting on Windows
|
||||
|
|
@ -202,15 +202,15 @@ Services require admin rights to install and tie the gateway's lifecycle to mach
|
|||
|
||||
| Path | Contents |
|
||||
|---|---|
|
||||
| `%LOCALAPPDATA%\hermes\hermes-agent\` | Git checkout + venv. Safe to `Remove-Item -Recurse` and reinstall. |
|
||||
| `%LOCALAPPDATA%\hermes\hermes-agent\` | Git checkout + venv. `venv\Scripts\hermes.exe` is the command added to User PATH. Safe to `Remove-Item -Recurse` and reinstall. |
|
||||
| `%LOCALAPPDATA%\hermes\git\` | PortableGit (only if the installer provisioned it). |
|
||||
| `%LOCALAPPDATA%\hermes\node\` | Portable Node.js (only if the installer provisioned it). |
|
||||
| `%LOCALAPPDATA%\hermes\bin\` | `hermes.cmd` shim, added to User PATH. |
|
||||
| `%USERPROFILE%\.hermes\` | Your config, auth, skills, sessions, logs. **Survives reinstalls.** |
|
||||
| `%LOCALAPPDATA%\hermes\bin\` | Hermes's managed `uv.exe` (the Python manager it uses for updates). |
|
||||
| `%LOCALAPPDATA%\hermes\` (root) | Your config, auth, skills, sessions, logs (`config.yaml`, `.env`, `skills\`, `sessions\`, `logs\`, …). **Survives reinstalls.** |
|
||||
|
||||
The split is deliberate: `%LOCALAPPDATA%\hermes` is disposable infrastructure (you can blow it away and the one-liner restores it). `%USERPROFILE%\.hermes` is your data — config, memory, skills, session history — and is identical in shape to a Linux install. Mirror it between machines and your Hermes moves with you.
|
||||
On native Windows the installer sets `HERMES_HOME=%LOCALAPPDATA%\hermes`, so your data and the disposable install live under the **same** `%LOCALAPPDATA%\hermes` root: the install/runtime is the `hermes-agent\`, `git\`, `node\`, and `bin\` subdirectories, while your data files sit directly in `%LOCALAPPDATA%\hermes`. Reinstalling only replaces the `hermes-agent\` checkout, so your data survives — but because the two share a root, **don't** `Remove-Item -Recurse %LOCALAPPDATA%\hermes` if you want to keep your data; delete the `hermes-agent\` subdirectory instead. Your data directory is identical in shape to a Linux `~/.hermes`, so you can mirror it between machines.
|
||||
|
||||
**Override `HERMES_HOME`:** set the environment variable to point at a different data dir. Works the same as on Linux.
|
||||
**Override `HERMES_HOME`:** set the environment variable to point at a different data dir (e.g. `%USERPROFILE%\.hermes` to match a Linux/WSL layout). Works the same as on Linux.
|
||||
|
||||
## Browser tool
|
||||
|
||||
|
|
@ -235,7 +235,7 @@ hermes --version
|
|||
|
||||
### Environment variables
|
||||
|
||||
Hermes honors both `$env:X` (process-scope) and User environment variables (permanent, set in System Properties → Environment Variables). Setting API keys in `%USERPROFILE%\.hermes\.env` is the normal path — same as Linux:
|
||||
Hermes honors both `$env:X` (process-scope) and User environment variables (permanent, set in System Properties → Environment Variables). Setting API keys in `%LOCALAPPDATA%\hermes\.env` (your `HERMES_HOME`) is the normal path — same as Linux:
|
||||
|
||||
```
|
||||
OPENROUTER_API_KEY=sk-or-...
|
||||
|
|
@ -262,14 +262,15 @@ From PowerShell:
|
|||
hermes uninstall
|
||||
```
|
||||
|
||||
That's the clean path — removes the schtasks entry, Startup folder shortcut, `hermes.cmd` shim, deletes `%LOCALAPPDATA%\hermes\hermes-agent\`, and trims the User PATH. It leaves `%USERPROFILE%\.hermes\` alone (your config, auth, skills, sessions, logs) in case you're reinstalling.
|
||||
That's the clean path — removes the schtasks entry, Startup folder shortcut, `hermes.cmd` shim, deletes `%LOCALAPPDATA%\hermes\hermes-agent\`, and trims the User PATH. It leaves the rest of `%LOCALAPPDATA%\hermes\` alone (your config, auth, skills, sessions, logs) in case you're reinstalling.
|
||||
|
||||
To nuke everything:
|
||||
|
||||
```powershell
|
||||
hermes uninstall
|
||||
Remove-Item -Recurse -Force "$env:USERPROFILE\.hermes"
|
||||
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\hermes"
|
||||
# Also remove a legacy CLI/WSL data dir if you ever used one:
|
||||
Remove-Item -Recurse -Force "$env:USERPROFILE\.hermes"
|
||||
```
|
||||
|
||||
The `hermes uninstall` CLI subcommand also handles the case where the schtasks entry was registered under a different task name (older installs) — it searches by install path rather than by hardcoded task name.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue