Summary
When MemTensor runs inside a Docker container and the daemon is started directly from the container's entrypoint.sh (instead of being lazily spawned by the Python adapter's bridge_client.py), the bridge process cannot locate its config.yaml, resulting in:
- No embedding provider — falls back to
local or disabled
- No LLM provider — summarization/reflection features break
- Wrong data directory — falls back to
~/.openharness/memos-state (empty) instead of ~/.hermes/memos-plugin/data/
- Lost branding — no custom title/logo
Root Cause
core/config/paths.ts resolves the runtime home via:
MEMOS_HOME env varMEMOS_CONFIG_FILE env var- Built-in default:
~/.<agent>/memos-plugin/
When the Docker entrypoint starts the daemon with just node bridge.cts --agent=hermes, none of these env vars are set. In v1.x, MEMOS_BRIDGE_CONFIG was used but only carried stateDir, missing config and branding. In v2.0, the YAML-based config system is cleaner but still requires either:
MEMOS_HOME pointing to the correct runtime directory, orconfig.yaml existing at ~/.hermes/memos-plugin/config.yaml
In a Docker container where HOME=/opt/data, the default resolves to /opt/data/.hermes/memos-plugin/ which may not exist or may not have the config file generated by install.sh.
Environment
- Hermes Agent in Docker (official
nousresearch/hermes-agent image)
- MemOS v1.0.3 (also reproducible conceptually with v2.0-alpha)
- MemTensor installed via
install.sh to /opt/data/home/.hermes/memos-plugin/
- Container
entrypoint.sh starts daemon as a background service before Hermes main process
Workaround (current)
We created a start_memtensor.sh script on the persistent volume that:
- Reads
openclaw.json to extract Siliconflow embedding/LLM config
- Injects full
MEMOS_BRIDGE_CONFIG with stateDir, config, and branding
- Starts the daemon with proper environment
This works but is fragile and couples the startup script to a specific provider's config format.
Suggested Fix
- Document
MEMOS_HOME and MEMOS_CONFIG_FILE env vars prominently in the README and Docker deployment guide
- Add a
--home CLI flag to bridge.cts as an alternative to env vars (easier for Docker CMD/ENTRYPOINT)
- Add a Docker deployment example showing proper env var setup
- Graceful fallback: when
config.yaml is missing, log a clear warning with the expected path and a link to the configuration docs
Related Files
apps/memos-local-plugin/core/config/paths.ts — env var resolutionapps/memos-local-plugin/bridge.cts — daemon entry pointapps/memos-local-plugin/templates/config.hermes.yaml — config templateapps/memos-local-plugin/install.sh — generates config.yaml at install time
Happy to submit a PR with the documentation improvements and --home flag.
Summary
When MemTensor runs inside a Docker container and the daemon is started directly from the container's
entrypoint.sh(instead of being lazily spawned by the Python adapter'sbridge_client.py), the bridge process cannot locate itsconfig.yaml, resulting in:localor disabled~/.openharness/memos-state(empty) instead of~/.hermes/memos-plugin/data/Root Cause
core/config/paths.tsresolves the runtime home via:MEMOS_HOMEenv varMEMOS_CONFIG_FILEenv var~/.<agent>/memos-plugin/When the Docker entrypoint starts the daemon with just
node bridge.cts --agent=hermes, none of these env vars are set. In v1.x,MEMOS_BRIDGE_CONFIGwas used but only carriedstateDir, missingconfigandbranding. In v2.0, the YAML-based config system is cleaner but still requires either:MEMOS_HOMEpointing to the correct runtime directory, orconfig.yamlexisting at~/.hermes/memos-plugin/config.yamlIn a Docker container where
HOME=/opt/data, the default resolves to/opt/data/.hermes/memos-plugin/which may not exist or may not have the config file generated byinstall.sh.Environment
nousresearch/hermes-agentimage)install.shto/opt/data/home/.hermes/memos-plugin/entrypoint.shstarts daemon as a background service before Hermes main processWorkaround (current)
We created a
start_memtensor.shscript on the persistent volume that:openclaw.jsonto extract Siliconflow embedding/LLM configMEMOS_BRIDGE_CONFIGwithstateDir,config, andbrandingThis works but is fragile and couples the startup script to a specific provider's config format.
Suggested Fix
MEMOS_HOMEandMEMOS_CONFIG_FILEenv vars prominently in the README and Docker deployment guide--homeCLI flag tobridge.ctsas an alternative to env vars (easier for Docker CMD/ENTRYPOINT)config.yamlis missing, log a clear warning with the expected path and a link to the configuration docsRelated Files
apps/memos-local-plugin/core/config/paths.ts— env var resolutionapps/memos-local-plugin/bridge.cts— daemon entry pointapps/memos-local-plugin/templates/config.hermes.yaml— config templateapps/memos-local-plugin/install.sh— generates config.yaml at install timeHappy to submit a PR with the documentation improvements and
--homeflag.