Environment
- @agentmemory/agentmemory 0.9.28 + @agentmemory/mcp 0.9.28 (global npm install)
- iii engine v0.11.2, launched via launchd (
com.local.iii)
- macOS 27.0 (arm64), Node v26.5.1
Repro
- iii daemon running normally (REST on 3111, streams 3112, viewer 3113).
/agentmemory/health returns healthy, smart-search works.
- Run
agentmemory consolidate from a shell while the daemon is up.
- Observe the CLI boot a second full instance: it prints the whole startup banner (REST/Viewer/Streams/Engine), logs
[iii] Worker registered with ID: … against the running engine, and the viewer falls back to port 3114 (Viewer started on http://localhost:3114 (fallback from 3113)).
- CLI prints
Shutting down... twice and exits.
Observed
After the CLI exits, the original daemon is broken:
- Port 3111 still LISTENs, but every
/agentmemory/* route returns 404 (smart-search, health, all of them).
/agentmemory/health unreachable from monitoring, while the iii process itself is still alive and its engine port responds.- No consolidation report is emitted, so it is unclear whether the sweep ran at all.
Best guess from the outside: the CLI instance registers itself as a worker on the already-running engine, and its shutdown tears down the HTTP trigger registrations that belong to the daemon's worker.
Expected
Either (a) the CLI detects a running daemon and routes the command through it (the HTTP POST /agentmemory/consolidate endpoint already exists and works fine against the live daemon - that was our workaround), or (b) it refuses to start with a clear "daemon already running, use the API or stop it first" error. Silently corrupting the live daemon's routing is the worst of both.
Recovery
Full bounce required: launchctl bootout gui/$UID/com.local.iii + pkill -9 orphans + launchctl bootstrap - after which routes come back.
Related note
While draining stale sessions we also noticed POST /agentmemory/evict returns an empty-body response early while the sweep keeps running server-side for ~45 minutes (progress only observable by polling GET /agentmemory/sessions). A job id / status endpoint for long-running lifecycle ops would help. Happy to split that into a separate issue if you prefer.
Environment
com.local.iii)Repro
/agentmemory/healthreturns healthy, smart-search works.agentmemory consolidatefrom a shell while the daemon is up.[iii] Worker registered with ID: …against the running engine, and the viewer falls back to port 3114 (Viewer started on http://localhost:3114 (fallback from 3113)).Shutting down...twice and exits.Observed
After the CLI exits, the original daemon is broken:
/agentmemory/*route returns 404 (smart-search, health, all of them)./agentmemory/healthunreachable from monitoring, while the iii process itself is still alive and its engine port responds.Best guess from the outside: the CLI instance registers itself as a worker on the already-running engine, and its shutdown tears down the HTTP trigger registrations that belong to the daemon's worker.
Expected
Either (a) the CLI detects a running daemon and routes the command through it (the HTTP
POST /agentmemory/consolidateendpoint already exists and works fine against the live daemon - that was our workaround), or (b) it refuses to start with a clear "daemon already running, use the API or stop it first" error. Silently corrupting the live daemon's routing is the worst of both.Recovery
Full bounce required:
launchctl bootout gui/$UID/com.local.iii+pkill -9orphans +launchctl bootstrap- after which routes come back.Related note
While draining stale sessions we also noticed
POST /agentmemory/evictreturns an empty-body response early while the sweep keeps running server-side for ~45 minutes (progress only observable by pollingGET /agentmemory/sessions). A job id / status endpoint for long-running lifecycle ops would help. Happy to split that into a separate issue if you prefer.