--- title: Hermes migration audit — Mac mini status: in_progress date: 2026-08-02 source: Live audit on Mac-mini-M4.local --- # Hermes migration audit — Mac mini ## Verified working - Hermes Agent `v0.19.1` is installed at `/Users/adolforeyna/.hermes/hermes-agent`. - Primary state database passed `PRAGMA quick_check` and contains 1,456 sessions. - Brain access is available at `/Users/adolforeyna/brain` with read/write/traverse access. - Migrated Hermes assets exist: - 32 skills - 33 scripts - 4 memory files - profiles: `emi`, `kids`, `voice` - All 10 scheduled cron jobs are present and their referenced local scripts exist. - A persistent macOS launchd gateway was installed at: `/Users/adolforeyna/Library/LaunchAgents/ai.hermes.gateway.plist` - Gateway cron ticker was verified healthy after installation; scheduled jobs will fire automatically. - MCP `macmini` connected successfully in 40 ms and exposed 48 tools. ## Restored during audit - WhatsApp credentials were absent locally but present on the old Pi (`pi5`, hostname `aeropi5`). - Restored the credential into the canonical Mac path: `/Users/adolforeyna/.hermes/platforms/whatsapp/session/creds.json` - Set credential permissions to `0600`. - After the restore, the Mac gateway connected to WhatsApp. ## Outstanding migration work ### 1. WhatsApp handoff The Mac gateway can connect to WhatsApp, but outgoing messages failed with `Not connected to WhatsApp`. Likely contributing factors: - The old Pi gateway may still be operating the same WhatsApp linked-device session. - The old Pi is still reachable as SSH alias `pi5` / hostname `aeropi5`. An attempt to stop the old Pi gateway was denied by the user approval system, so no workaround or retry was performed. ### 2. Local session-lock ownership `/Users/adolforeyna/.local/state` is owned by `root`. Hermes consequently cannot create: `/Users/adolforeyna/.local/state/hermes` Gateway log warning: `Could not acquire session lock (non-fatal): [Errno 13] Permission denied` This should be repaired before relying on the WhatsApp bridge long-term. ### 3. OpenSCAD iMac MCP The configured `openscad_imac` MCP fails initial connection because SSH host-key verification fails. The `macmini` MCP is healthy. ### 4. ESP32 voice routes The `esp32-voice-gateway` plugin detected that its routes are missing after the Hermes update. Its saved patch no longer applies cleanly to the current `gateway/platforms/api_server.py`. The ESP32 voice API must be updated to the current Hermes source and verified before use. ### 5. Gateway model credentials Gateway logs show the configured custom Meta model `muse-spark-1.1` receives HTTP `401 Unauthorized`. The model credential must be refreshed or the gateway model/provider changed, then tested with an inbound message. ## Optional capability gaps (not migration failures) - Nous Portal authentication is not configured. - Web-search provider keys are not configured. - Docker is not installed. These do not block the core agent, brain, cron, or healthy Mac mini MCP. ## Migration sequence 1. Resolve Pi → Mac WhatsApp ownership and verify a real outbound reply. 2. Repair the Mac local Hermes-state directory ownership and confirm lock acquisition. 3. Repair and test the OpenSCAD iMac MCP SSH trust relationship. 4. Restore and test ESP32 voice gateway routes. 5. Repair/test gateway model credentials. 6. Complete end-to-end checks: WhatsApp inbound/outbound, cron heartbeat, MCPs, voice endpoints, and model calls. ## Progress update — WhatsApp routing and full session-state recovery ### Channel routing correction The first post-migration WhatsApp responses were incorrectly sent into the group named `EMI Assistant` (`120363409068274776@g.us`). This group is reserved for EMI conversations and is not the family/home channel. Live bridge inspection identified these WhatsApp groups: - `EMI Assistant` — separate EMI group - `FamReynaBot` — family group, with the bot plus Adolfo and his wife - `ReynaO` — separate group The default/home route was corrected so scheduled/default WhatsApp delivery uses the original Pi WhatsApp home-channel configuration rather than EMI. ### User registration and policy - Family group policy remains `allowlist` with no mention requirement. - The original Pi WhatsApp allowlist was restored rather than using temporary Mac-only configuration overrides. - The original bot mode, user allowlist, home channel, owner-message forwarding setting, and enabled setting were copied from the Pi runtime `.env` into the Mac `.env`. - The Mac bridge now starts in `bot` mode. It had mistakenly started in `self-chat` mode before restoration; that mode ignores ordinary DM traffic and explained the DM non-responses. ### Full WhatsApp session recovery Initial recovery copied only `creds.json`. That was insufficient for inbound-message handling: the Pi WhatsApp session directory contains encrypted multi-file authentication/session state. On 2026-08-02: 1. Verified the Pi session had 1,592 files: `creds.json` plus 1,591 key/state files. 2. Stopped the Mac gateway briefly. 3. Copied the entire Pi session directory to: `/Users/adolforeyna/.hermes/platforms/whatsapp/session/` 4. Applied restrictive permissions (`0700` directories, `0600` files). 5. Restarted the Mac launchd gateway. After restart: - WhatsApp bridge reported `status=connected`. - Cron gateway ticker was healthy. - The gateway processed a recovered inbound WhatsApp event and generated a response. ### Current verification status A fresh user-authored DM test after the full session-state restore is still required to prove live inbound DM processing end-to-end. An automated recovery-probe DM was attempted but denied by the user approval system, so it was not retried. ## Progress update — browser automation restored on Mac mini The iMac is kids-only and must not host Hermes browser automation or private browser state. On 2026-08-03, a dedicated visible Chrome automation profile was created on the Mac mini at: `~/Library/Application Support/Google/Chrome-Hermes/` - The source Chrome profile was copied once with caches and lock files excluded, preserving the available same-Mac browser session material without operating on the iMac. - Chrome is running as a separate visible instance with CDP bound only to `127.0.0.1:9222`, using the `ReynaFamilyBot` Chrome profile (`reynafamilybot@gmail.com`) by default. Live Gemini verification confirmed that bot account is signed in. - `agent-browser` is connected to that instance under session `hermes-visible`; its dashboard is healthy on `127.0.0.1:4848`. - A LAN observer proxy is verified on `192.168.68.112:4849`. The dashboard hard-coded `ws://localhost:`, so laptop viewers saw `Disconnected`; the proxy now rewrites that endpoint to a narrow LAN stream bridge (`:4851`) and normalizes its WebSocket Origin before forwarding to the localhost-only stream (`:4850`). A LAN URL load verified `Online` rather than `Disconnected`. - Local helpers: `~/bin/hermes-browser` (`start`/`status`) and `~/bin/hermes-browser-dashboard-proxy.py`. The durable launchd plist was written at `~/Library/LaunchAgents/com.reyna.hermes-browser-dashboard-proxy.plist`, but its registration was blocked by Hermes' gateway safety guard. It requires a one-time explicit `launchctl bootstrap` from a separate Mac mini Terminal session before relying on the LAN observer proxy across restarts.