coleam00/Archon · error · Error

Cannot confirm the isolation container owned by run ${resolv

Error message

Cannot confirm the isolation container owned by run ${resolvedId}. The run was not changed; inspect the managed containers before retrying or abandoning it.

What it means

After finding the run's `isolation_env_id`, the CLI looks it up in the isolation registry and requires it to be an actual `provider === 'container'` environment. If the registry record is absent or a different provider type, it refuses to cancel the run unchanged so the operator can inspect managed containers first.

Source

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

    if (current.status !== 'running') {
      throw new Error(
        `Cannot actively cancel run with status '${current.status}'. Only a running detached CLI run has live work to stop.`
      );
    }

    let containerEnvId: string | undefined;
    if (current.metadata?.isolation === 'container') {
      const isolationEnvId = current.metadata.isolation_env_id;
      if (typeof isolationEnvId !== 'string' || isolationEnvId.trim().length === 0) {
        throw new Error(
          `Cannot confirm the isolation container owned by run ${resolvedId}. ` +
            'The run was not changed; its container tracking ID is missing.'
        );
      }
      containerEnvId = isolationEnvId;
      const containerEnv = await isolationDb.getById(containerEnvId);
      if (containerEnv?.provider !== 'container') {
        throw new Error(
          `Cannot confirm the isolation container owned by run ${resolvedId}. ` +
            'The run was not changed; inspect the managed containers before retrying or abandoning it.'
        );
      }
    }

    const target = await requestDetachedRunStop(resolvedId);
    await target.stop();

    if (containerEnvId) {
      try {
        await reclaimContainerEnv(containerEnvId);
      } catch (error) {
        throw new Error(
          'Detached owner process stopped, but the isolation container could not be confirmed stopped. ' +
            `Run state was not changed. ${(error as Error).message}`
        );
      }

View on GitHub (pinned to 0773b97458)

Solutions

  1. List managed containers/environments in the isolation registry and match the run's container manually
  2. Correct the run's `isolation_env_id` (scratch DB) if it points at the wrong record
  3. Reclaim the container out-of-band, then proceed with the cancel once tracking is consistent

Example fix

// before
await cancelWorkflow(runId); // throws: env not a container
// after
const env = await isolationDb.getById(run.metadata.isolation_env_id);
if (env?.provider !== 'container') console.error('tracked env is not a container; inspect managed containers');
else await cancelWorkflow(runId);
Defensive patterns

Strategy: validation

Validate before calling

const env = await isolationDb.getById(run.metadata.isolation_env_id);
if (env?.provider !== 'container') {
  throw new Error(`tracked env ${run.metadata.isolation_env_id} is not a container (${env?.provider ?? 'missing'})`);
}

Type guard

const isContainerEnv = (e: { provider?: string } | null | undefined): e is { provider: 'container' } =>
  e?.provider === 'container';

Prevention

When it happens

Trigger: Cancelling a container-isolated run whose `isolation_env_id` points to a deleted registry entry or to a non-container environment type (e.g. a worktree env).

Common situations: Container registry rows garbage-collected while the run row still references them; run metadata pointing at the wrong environment ID; environment recreated under a new ID.

Related errors


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