coleam00/Archon · error · Error

classifyIsolationError(err)

Error message

classifyIsolationError(err)

What it means

When resuming a detached workflow run that used a container isolation environment, `backend.resumeEnv(resumeEnvId)` can fail; the CLI wraps the failure via `classifyIsolationError(err)` (packages/isolation/src/errors.ts:160), which pattern-matches message/stderr into an actionable message (daemon down, image missing, docker-group permissions) or a generic 'Could not create isolated workspace' fallback.

Source

Thrown at packages/cli/src/commands/workflow.ts:2534

            ? resumable.metadata.isolation_env_id
            : undefined;
        if (!resumeEnvId) {
          throw new Error(
            `Cannot resume container run '${resumable?.id ?? '?'}': its isolation env id is ` +
              'missing from the run metadata. Start a fresh --container run instead.'
          );
        }
        console.log(`Folder project — resuming container run (image ${containerConfig.image}).`);
        getLog().info(
          { envId: resumeEnvId, image: containerConfig.image },
          'workflow.resuming_in_container'
        );
        try {
          prepared = await backend.resumeEnv(resumeEnvId);
        } catch (resumeErr) {
          const err = resumeErr as Error;
          getLog().error({ err, envId: resumeEnvId }, 'workflow.container_resume_failed');
          throw new Error(classifyIsolationError(err));
        }
      } else {
        console.log(`Folder project — running in container (image ${containerConfig.image}).`);
        getLog().info(
          { cwd: codebase.default_cwd, image: containerConfig.image },
          'workflow.running_in_container'
        );
        try {
          // The container fixes its mounts at creation, so the run's source must already
          // be at its final path. Move it there now; executeWorkflow recomputes the same
          // destination and skips its own move.
          if (preparedSource) {
            preparedSource = await finalizeWorkflowSource(createWorkflowDeps(), preparedSource, {
              cwd: folderCodebase.defaultCwd,
              codebaseId: folderCodebase.id,
            });
            // Finalization moved the capture, so keep ownership on the path that now
            // exists. If container preparation fails below, the wrap reclaims the

View on GitHub (pinned to 0773b97458)

Solutions

  1. Start the Docker daemon and verify with `docker info`, then re-run the resume command.
  2. Check `docker images` for the configured runner image; rebuild/pull it if pruned.
  3. Add your user to the docker group (`sudo usermod -aG docker $USER`) and re-login, or fix DOCKER_HOST permissions.
  4. If the env is unrecoverable, delete the stale isolation env record and start a fresh run instead of resuming.

Example fix

// before
throw new Error(classifyIsolationError(err));
// after
getLog().error({ err }, 'workflow.container_resume_failed');
throw new Error(`${classifyIsolationError(err)}\n(Original error: ${err.message})`);
Defensive patterns

Strategy: try-catch

Validate before calling

// preflight before containerized resume
const docker = Bun.$`docker info`.nothrow().quiet();
if (docker.exitCode !== 0) throw new Error('Docker daemon not reachable; start Docker before resuming');

Type guard

function isIsolationError(e: unknown): e is Error & { stderr?: string } {
  return e instanceof Error && ('stderr' in e ? typeof (e as { stderr?: unknown }).stderr === 'string' || (e as { stderr?: unknown }).stderr === undefined : true);
}

Try / catch

try {
  prepared = await backend.resumeEnv(resumeEnvId);
} catch (err) {
  const e = err as Error;
  if (!isKnownIsolationError(e)) throw e; // surface unknown bugs
  console.error(classifyIsolationError(e));
  process.exitCode = 1;
}

Prevention

When it happens

Trigger: Running `archon workflow <name>` for a resumable run whose isolation env is container-based and `resumeEnv` throws: docker daemon not running, container/image removed, docker socket permission denied, or a stale/unrecoverable env record.

Common situations: Docker Desktop was stopped or upgraded between the original run and the resume; the runner image was pruned with `docker image prune -a`; the user is not in the `docker` group on Linux; a reboot removed the container the env pointed to.

Related errors


AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/4a57bf9364d754c2. Report an issue: GitHub.