fix: install.ps1 writes Hermes config template to the wrong location - #2211
fix: install.ps1 writes Hermes config template to the wrong location#2211asorry75 wants to merge 2 commits into
Conversation
Install-Hermes sets $HomeDir = $Prefix (%LOCALAPPDATA%\hermes\memos-plugin),
but the daemon reads its runtime config from ~/.hermes/memos-plugin
(Path.home() based). The template config.yaml therefore lands where the
daemon never looks: after a fresh install on Windows the LLM summarizer
and skill-evolution stay disabled ("config file not found ... using
defaults").
Align with the OpenClaw branch which already splits the runtime home:
use ~/.hermes\memos-plugin for Hermes.
🤖 Open Code ReviewTarget: PR #2211 🔍 OpenCodeReview found 1 issue(s) in this PR. 1.
|
|
Thanks for the review. A few clarifications from the reporter side: 1. This is not a path change — the path was wrong from day one for new installs. We hit this as a brand-new user (first install, no legacy data): after a clean Windows install, the daemon logs The OpenClaw branch already sets 2. Same root cause, second manifestation: #2210 The native-memory import path ( 3. Migration for existing users — agreed, and which approach do you prefer? Existing installs may have runtime data under the old (wrong) location, possibly mixed with the code. Options:
Happy to implement whichever fits this repo best. |
|
…r#2221) The memos-local-plugin resolved the Hermes home as ~/.hermes in several places, while Hermes itself uses %LOCALAPPDATA%\hermes on Windows (HERMES_HOME). The plugin's runtime data, PID files, and native import sources therefore landed outside Hermes' real home on Windows: install config never reached the daemon (MemTensor#2211), native memory import missed MEMORY.md (MemTensor#2210), hermes backup could skip plugin state, and host and plugin tooling disagreed on where the data lived. Add a single canonical Hermes-home resolver on each language side that mirrors Hermes' own _get_platform_default_hermes_home: - Python: adapters/hermes/memos_provider/hermes_home.py - TypeScript: core/config/hermes-home.ts Resolution: HERMES_HOME env -> %LOCALAPPDATA%\hermes on win32 (with ~/AppData/Local/hermes fallback) -> ~/.hermes elsewhere. All hard-coded sites now route through it: the Python provider fallback + child-session lookup, the bridge_client runtime home, both bridge.cts/bridge.mts pidFilePath resolvers, core/config/paths.ts resolveHome (hermes default), and the migrate + import-export server routes. Non-Hermes agents (openclaw, custom) keep the ~/.<agent>/memos-plugin convention. MEMOS_HOME / MEMOS_CONFIG_FILE still win over HERMES_HOME. Tests: added tests/python/test_hermes_home.py (8 tests) and tests/unit/config/hermes-home.test.ts (6 tests) covering all four resolver branches plus the Python provider / bridge_client integration paths. Extended tests/unit/config/paths.test.ts with a resolveHome("hermes") + HERMES_HOME regression assertion. Full Python suite (109) and full vitest suite (1274) pass; tsc --noEmit clean.
|
Summary
On a fresh Windows install, the Hermes branch of
install.ps1writes the templateconfig.yamlto the wrong location:The daemon reads its runtime config from
~/.hermes/memos-plugin(resolved fromPath.home()inbridge_client.py/ the bridge), so right after installation the log shows:Result: the LLM summarizer and skill-evolution stay disabled on Windows even though the install reported success. Local embedding still works, which makes the failure easy to miss.
Changes
Use the same split as the OpenClaw branch (which already sets
$HomeDir = ~/.openclaw\memos-plugin):Test
Related to #2221 (systemic Hermes home resolution on Windows).
Note (2026-08-05): #2224 (systemic fix for #2221) covers runtime path resolution;
install.ps1is outside its scope, so this PR addresses the install-script half of the same bug family.