Worker service did not confirm shutdown; continuing uninstal

Error message

Worker service did not confirm shutdown; continuing uninstall cleanup.

What it means

During `npx claude-mem uninstall`, the command calls shutdownWorkerAndWait(workerPort, 10000) to stop the worker. If the worker was running but did not confirm a clean stop within the 10-second window (result.workerWasRunning && !result.stopped), the command logs this warning and proceeds with uninstall cleanup anyway. The library continues because uninstall can remove files regardless of a lingering worker, though the process may keep running afterward.

Source

Thrown at src/npx-cli/commands/uninstall.ts:277

  } else if (process.stdin.isTTY) {
    const shouldContinue = await p.confirm({
      message: 'Are you sure you want to uninstall claude-mem?',
      initialValue: false,
    });

    if (p.isCancel(shouldContinue) || !shouldContinue) {
      p.cancel('Uninstall cancelled.');
      return;
    }
  }

  const workerPort = SettingsDefaultsManager.get('CLAUDE_MEM_WORKER_PORT');
  try {
    const result = await shutdownWorkerAndWait(workerPort, 10000);
    if (result.workerWasRunning && result.stopped) {
      p.log.info('Worker service stopped.');
    } else if (result.workerWasRunning) {
      p.log.warn('Worker service did not confirm shutdown; continuing uninstall cleanup.');
    }
  } catch (error: unknown) {
    console.warn('[uninstall] Worker shutdown attempt failed:', error instanceof Error ? error.message : String(error));
  }

  // #2568 — server-runtime teardown. Gated on the installed/selected runtime so
  // the worker uninstall path is completely unchanged. The bundled Docker
  // compose stack lives under the marketplace dir; if it's present we treat the
  // stack as locally managed and instruct teardown (the actual `docker compose
  // down -v` is an operator/CI side effect, not run from this Node process).
  const selectedRuntime = readSelectedRuntime();
  if (selectedRuntime === 'server') {
    if (existsSync(join(marketplaceDirectory(), 'docker-compose.yml'))) {
      p.log.info(
        'Server runtime detected. Tear down the bundled stack with '
          + '`docker compose down -v --remove-orphans` (stops + removes pg + redis/valkey).',
      );
    } else {

View on GitHub (pinned to 8bc631a71a)

Solutions

Let uninstall finish (it continues by design), then check for and manually kill any lingering claude-mem worker process.
Run `npx claude-mem stop` after uninstall to attempt a graceful stop of the leftover worker.
If the worker repeatedly ignores shutdown, kill it by PID and check worker logs for what blocked shutdown (e.g. stuck Chroma connection).
Stop the worker before uninstalling: `npx claude-mem stop` then `npx claude-mem uninstall`.

Example fix

// before
npx claude-mem uninstall   // warn: did not confirm shutdown
// after
npx claude-mem stop && npx claude-mem uninstall

Defensive patterns

Strategy: retry

Validate before calling

const res = await fetch(`http://127.0.0.1:${port}/health`, { signal: AbortSignal.timeout(2000) }).catch(() => null);
if (res && res.ok) console.log('worker running — stop it before uninstall');

Try / catch

try {
  const result = await shutdownWorkerAndWait(workerPort, 10000);
  if (result.workerWasRunning && !result.stopped) {
    console.warn('Worker did not confirm shutdown; check for leftover process after cleanup.');
  }
} catch (error) {
  console.warn('Worker shutdown attempt failed:', error instanceof Error ? error.message : String(error));
}

Prevention

Stop the worker gracefully (`npx claude-mem stop`) before uninstalling.
Verify the worker process exited after uninstall; kill leftovers by PID.
Check worker logs for long-running tasks (Chroma compaction) that block shutdown.
Re-run uninstall if a worker was left running to confirm a clean state.

When it happens

Trigger: Worker is running when uninstall starts, the stop request is sent, but the worker does not acknowledge shutdown within 10000 ms — hung worker, blocked event loop, stuck shutdown handler, or cleanup taking longer than the timeout.

Common situations: Worker wedged on a stuck Chroma/DB operation; worker busy processing a long observation compaction; slow machine or heavy load preventing the 10s window from being met; port reachable but process unresponsive to the shutdown command.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

AI-assisted analysis of thedotmack/claude-mem@8bc631a71a (2026-09-09). Data as JSON: /api/errors/09eae8a79e32e8e1. Report an issue: GitHub.