hermes - 💡(How to fix) Fix [Bug]: hindsight-embed pg0 hardcodes /opt/homebrew/ openssl path, crashes on user-level Homebrew installations

Bug Description

hindsight-embed (v0.7.1, bundled with hindsight-all) launches an embedded PostgreSQL instance (pg0) that hardcodes the openssl library path to /opt/homebrew/opt/openssl@3/lib/. On macOS systems where Homebrew is installed at a user-defined prefix (e.g., ~/homebrew/ instead of /opt/homebrew/), pg0 fails to start because the dynamic linker cannot find libssl.3.dylib and libcrypto.3.dylib.

This causes the hindsight daemon to hang during startup (178s timeout), breaking agent memory functionality for any user with a non-standard Homebrew installation.

Reproduction

Prerequisites: macOS with Homebrew at user-defined prefix (e.g., ~/homebrew/).

1. Install hindsight-all v0.7.1 (dep of hermes-agent)
2. Set memory.provider: hindsight in ~/.hermes/config.yaml
3. Start any agent session (CLI, TUI, or gateway)
4. Observe ~178s timeout while hindsight daemon attempts to start PostgreSQL
5. Check hindsight-embed.log for timeout, daemon.log for dyld error

Root Cause

The pg0 binary (embedded PostgreSQL shipped with hindsight-embed) is compiled against a Homebrew openssl with an absolute RPATH of /opt/homebrew/opt/openssl@3/lib/. This path does not respect the user's actual Homebrew prefix.

Affected binaries:

• .pg0/instances/hindsight-embed-hermes/bin/postgres
• .pg0/instances/hindsight-embed-hermes/bin/initdb
• .pg0/instances/hindsight-embed-hermes/bin/pg_ctl
• .pg0/instances/hindsight-embed-hermes/lib/*.dylib

Environment

• macOS 26.5 (Apple Silicon M5)
• Homebrew installed at ~/homebrew/ (user-level, not /opt/homebrew/)
• hindsight-all==0.7.1
• Python 3.11

Impact

• User-level Homebrew installations cannot use hindsight memory at all
• Users upgrading from 0.6.x to 0.7.1 experience silent regression
• 3-minute hang per turn (178s timeout) waiting for PostgreSQL
• No graceful degradation to builtin memory

Proposed Fix

Detect actual Homebrew openssl path at daemon startup and patch RPATH via install_name_tool:

REAL_OPENSSL=$(find ~ -name "libssl.3.dylib" -maxdepth 5 2>/dev/null | head -1)
OPENSSL_DIR=$(dirname "$REAL_OPENSSL")
for binary in bin/postgres bin/initdb bin/pg_ctl bin/postmaster; do
  install_name_tool -change \
    /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib \
    "$OPENSSL_DIR/libssl.3.dylib" "$binary" 2>/dev/null || true
done

Workaround (confirmed working)

Apply install_name_tool to the 7 affected binaries + dylibs inside the pg0 instance directory. Full patch: https://github.com/NousResearch/hermes-agent/issues/35200

Additional Issues Found During Investigation

1. hindsight-embed default profile — daemon start defaults to default profile (port 8888, no API key) instead of hermes profile (port 9177). Users who configure memory.provider: hindsight with a hermes profile get a dud daemon on the wrong port.

2. Env var name inconsistency — Error message asks for HINDSIGHT_API_LLM_API_KEY but some docs/components use HINDSIGHT_LLM_API_KEY.

3. HuggingFace download blocked in China — Initial model download (cross-encoder ~927MB, bge-small ~403MB) times out behind GFW. No fallback to hf-mirror.com.

Related

• #35184 — symlink skill discovery (cross-platform compatibility)
• Root issue introduced with hindsight-all v0.7.1 (embedded PostgreSQL migration)