nanocoai/nanoclaw · warning

Failed to list existing sessions for adoption

Error message

Failed to list existing sessions for adoption

What it means

At startup the host could not list running Docker containers for adoption, so no orphaned session containers were adopted or stopped. Existing containers keep running but are unsupervised by this host process.

Source

Thrown at src/container-runner.ts:388

  );
}

/**
 * Startup reconciliation: adopt what is still alive, stop what is not ours.
 *
 * This replaces the old reap-everything `cleanupOrphans()`. A surviving session
 * used to be destroyed on every host restart and its work recovered only
 * through the DB; now the host re-registers it and delivery resumes. The OneCLI
 * gateway resolves credentials per request on the host side, so an adopted
 * session's egress keeps working without any per-process state to rebuild.
 */
export async function adoptRunningSessions(): Promise<{ adopted: number; stopped: number }> {
  const driver = getSessionDriver();
  let snapshots: SupervisedSnapshot[];
  try {
    snapshots = await driver.listSessions(INSTALL_SLUG);
  } catch (err) {
    log.warn('Failed to list existing sessions for adoption', { err });
    return { adopted: 0, stopped: 0 };
  }

  let adopted = 0;
  let stopped = 0;
  for (const { handle, phase } of snapshots) {
    const session = handle.key.sessionId ? await getSession(handle.key.sessionId) : undefined;
    // The snapshot's phase is the listing's own truth: a corpse arrives as
    // 'terminal' (or not at all), so telling adoptable sessions apart needs
    // no per-handle status() round trip. `stop()` on a corpse is still full
    // teardown — a self-exited runtime needs its residue cleaned up.
    if (!session || session.status !== 'active' || phase !== 'running') {
      await handle.stop('orphan-at-startup').catch(() => {});
      stopped += 1;
      continue;
    }
    const runtime = registerRuntime(session.id, handle, handle.name, true);
    runtime.stopReason = undefined;

View on GitHub (pinned to 294ef2aee8)

Solutions

1. Verify `docker ps` works as the same user running nanoclaw
2. Restart the nanoclaw service after Docker is healthy: `systemctl --user restart nanoclaw`
3. Add Docker dependency ordering / retry to the service unit

execSync('docker ps'); // health gate before starting nanoclaw service

try { await adoptRunningSessions(); } catch { /* retry after Docker is confirmed up */ }

When it happens

Trigger: `driver.listSessions(INSTALL_SLUG)` throws — Docker CLI failure, daemon not yet up when nanoclaw starts (race at boot), or permission issues on the docker socket.

Common situations: systemd user service starting before Docker; user not in the docker group; Docker desktop mid-restart.

Related errors

• Failed to clean up orphaned containers
• --stdin-json input exceeds ${MAX_STDIN_JSON_BYTES} bytes
• --stdin-json input is not valid JSON
• --stdin-json input must be one JSON object
• Failed to chmod ncl socket (continuing)

AI-assisted analysis of nanocoai/nanoclaw@294ef2aee8 (2026-08-28). Data as JSON: /api/errors/f8f307ac0498c60e. Report an issue: GitHub.