claude-mem worker unreachable — hooks fail silently on every tool call after session start

[mykle0]

Plugin version: 13.5.5
OS: macOS (darwin)
Frequency: Persistent — occurs in 3+ separate sessions, survives app restarts

Symptom

Every tool call in a session produces this error in the hook output:

claude-mem worker unreachable for N consecutive hooks.

The counter increments on every hook (file-context, observation, summarize). Once it starts, it does not recover within the session.

Hooks affected

• file-context
• observation
• summarize

What was tried

• Restarted Claude Code — same behavior on next session
• Occurred across 3+ separate sessions on different days

Impact

• All memory/observation logging silently drops for the entire session
• Hook noise pollutes every tool call response (stop hook feedback messages surfaced in UI)
• MCP server (plugin_claude-mem_mcp-search) appears to still load but hook-based logging is non-functional

Expected behavior

Worker recovers or restarts automatically; hooks fail gracefully without surfacing raw error output to the user.

Worker path

~/.claude/plugins/cache/thedotmack/claude-mem/13.5.5/scripts/bun-runner.js + worker-service.cjs

[Goro2030]

Confirming this still reproduces on 13.6.1 (npm latest), on WSL2/Ubuntu — so it's not macOS-specific. I traced the mechanism and have a tested workaround + a concrete fix proposal.

Environment

• claude-mem 13.6.1, WSL2 Ubuntu (systemd=true), bun 1.3.11, node v22.19.0

Reproduction of the broken recovery path

Once the worker is unreachable, every recovery through worker-cli.js fails:

$ node scripts/worker-cli.js start
Failed to start: Process died during startup
$ node scripts/worker-cli.js restart
Failed to restart: Process died during startup

…yet the worker runs perfectly fine when launched directly. So the worker isn't the problem — the launch/health-gating logic is.

Root cause (scripts/worker-cli.js)

startWithBun() (Linux branch) spawns the worker detached, pipes its stdout/stderr into a stream owned by the short-lived worker-cli process, then gates readiness on the spawned PID:

const child = spawn(bun, [workerScript], {
  detached: true,
  stdio: ["ignore", "pipe", "pipe"],   // piped into a stream owned by worker-cli
  env: { ...process.env, CLAUDE_MEM_WORKER_PORT: String(port) },
  cwd: P,
});
const out = createWriteStream(logFile, { flags: "a" });
child.stdout?.pipe(out);
child.stderr?.pipe(out);
child.unref();
writePidFile({ pid: child.pid, ... });
return this.waitForHealth(child.pid, port);   // gates on the bootstrap PID

waitForHealth(pid, port, timeout = 1e4) {
  const start = Date.now();
  while (Date.now() - start < timeout) {
    if (!this.isProcessAlive(pid))
      return { success: false, error: "Process died during startup" };
    // ...health fetch...
  }
}

The bootstrap process exits quickly (the live worker ends up running as bun worker-service.cjs --daemon, i.e. it re-execs/daemonizes and the original PID exits). So:

1. waitForHealth sees isProcessAlive(bootstrapPid) === false and returns "Process died during startup" before any readiness fetch can succeed.
2. worker-cli then exits, tearing down the createWriteStream the detached child's stdout/stderr were piped into — so the daemon loses its stdio and dies too (closed-fd / EPIPE). Net result: no healthy worker at all.

The PID being waited on is the launcher, not the daemon recorded in worker.pid, and the child's lifetime is coupled to the launcher's stdio.

Verified workaround

Spawning worker-service.cjs directly and fully detached (no --daemon, stdio detached from the caller via </dev/null + its own session) starts cleanly, serves /health, and writes a valid worker.pid that the plugin's own hooks then recognize:

CLAUDE_MEM_DATA_DIR="$HOME/.claude-mem" \
CLAUDE_PLUGIN_ROOT="$PLUGIN_DIR" \
setsid nohup bun "$PLUGIN_DIR/scripts/worker-service.cjs" \
  >> "$HOME/.claude-mem/logs/worker-manual.log" 2>&1 < /dev/null &
disown

I wired this into a 2-minute cron watchdog that double-probes /health and respawns this way on failure — it has reliably kept the worker up, which also covers the "worker recovers/restarts automatically" expectation from the original report.

Suggested fix

1. Make /health (port) the authority in waitForHealth, not the launcher PID. Poll health for the full timeout window; only fail if health never comes up. If a liveness guard is desired, read the daemon PID from worker.pid (which the daemon rewrites), not the bootstrap PID.
2. Decouple the daemon's stdio from worker-cli. Instead of child.stdout.pipe(streamOwnedByCli), open the log file as an fd and pass it straight into spawn (stdio: ["ignore", fd, fd]) so the daemon's output survives the launcher exiting.
3. Optionally start the worker in its own session (setsid / detached + the fd stdio above) so its lifetime is fully independent of the launcher — matching the workaround that reliably works on WSL.

Happy to open a PR if maintainers are open to it. (Related: #2747 describes the same surface error and was closed "Not Planned".)

[thedotmack]

Consolidating into #3603 (plan-15). The root cause and fix sequencing are tracked there alongside the rest of the cluster — please follow that issue for progress.