hermes - 💡(How to fix) Fix Hindsight local_embedded profile env does not persist HINDSIGHT_EMBED_API_DATABASE_URL override

Summary

Hermes' Hindsight plugin does not currently persist/propagate HINDSIGHT_EMBED_API_DATABASE_URL into the profile-scoped embedded env file. In local_embedded mode this means the daemon can be forced back onto the default profile database URL (pg0://hindsight-embed-<profile>) even when the user/runtime needs to override it.

In my case this made Hermes repeatedly reconnect to a stale embedded pg0 instance with schema drift, and the daemon flapped unreachable from the TUI.

Environment

• Repo: NousResearch/hermes-agent
• Commit: f27fcb6a82b8487174ca941c15e7a5887371eede
• Hermes home: ~/.hermes
• Hindsight mode: local_embedded
• Observed on macOS

What I observed

Hermes showed Hindsight as installed/available, but the embedded daemon was not healthy:

• curl http://127.0.0.1:9177/health failed
• no listener on 9177
• agent.log repeatedly logged that the embedded daemon was unreachable

The stale embedded postgres instance for the profile (pg0://hindsight-embed-hermes) was throwing repeated schema errors:

ERROR:  function schemas_with_pending_work() does not exist
STATEMENT:  SELECT * FROM schemas_with_pending_work()

I migrated a healthy pg0 database separately and wanted Hermes to point the embedded daemon at that database instead.

Root cause

The plugin writes a profile env file for standalone hindsight-embed consumption in:

• plugins/memory/hindsight/__init__.py
• _build_embedded_profile_env()

That env builder includes LLM settings and idle timeout, but not the embedded DB override.

Later, hindsight_embed.daemon_embed_manager.DaemonEmbedManager does support the override:

db_override = config.get("HINDSIGHT_EMBED_API_DATABASE_URL") or env.get("HINDSIGHT_EMBED_API_DATABASE_URL")
if db_override:
    env["HINDSIGHT_API_DATABASE_URL"] = db_override
else:
    env["HINDSIGHT_API_DATABASE_URL"] = self.get_database_url(profile)

So the lower layer is already capable of honoring the override, but the Hermes plugin never materializes it into the profile env file, which makes the override easy to lose across restarts/reinitialization.

Minimal local fix

This local patch was enough for me:

diff --git a/plugins/memory/hindsight/__init__.py b/plugins/memory/hindsight/__init__.py
@@
     current_provider = config.get("llm_provider", "")
     current_model = config.get("llm_model", "")
     current_base_url = config.get("llm_base_url") or os.environ.get("HINDSIGHT_API_LLM_BASE_URL", "")
+    current_database_url = (
+        config.get("embed_database_url")
+        or config.get("database_url")
+        or config.get("HINDSIGHT_EMBED_API_DATABASE_URL")
+        or os.environ.get("HINDSIGHT_EMBED_API_DATABASE_URL", "")
+    )
@@
     if current_base_url:
         env_values["HINDSIGHT_API_LLM_BASE_URL"] = str(current_base_url)
+    if current_database_url:
+        env_values["HINDSIGHT_EMBED_API_DATABASE_URL"] = str(current_database_url)

With that patch plus a config value:

{
  "HINDSIGHT_EMBED_API_DATABASE_URL": "pg0://hindsight"
}

Hermes successfully started the embedded daemon on 9177, and /health returned:

{"status":"healthy","database":"connected"}

The daemon log also showed it was now connected to the intended database instead of the stale profile database.

Expected behavior

If a user sets HINDSIGHT_EMBED_API_DATABASE_URL in Hermes' Hindsight config/runtime, Hermes should persist that into the profile-scoped embedded env it materializes, so the embedded daemon reliably honors the intended database across restarts.

Why this matters

Without this, a user can fix or migrate the Hindsight database but Hermes may still silently reconnect to the old per-profile pg0 instance on the next daemon start, which is especially painful when the old instance has schema drift or broken state.