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
- List managed containers/environments in the isolation registry and match the run's container manually
- Correct the run's `isolation_env_id` (scratch DB) if it points at the wrong record
- 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
- Keep the isolation registry and run metadata in a consistent state; avoid out-of-band deletions
- List managed containers before cancelling container-isolated runs
- Reconcile stale registry references via a scratch DB before cancel
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
- Cannot confirm the isolation container owned by run ${resolv
- Detached owner process stopped, but the isolation container
- Workflow run not found: ${resolvedId}
- Cannot actively cancel run with status '${current.status}'.
- Detached work stopped, but cancellation did not win the run
AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01).
Data as JSON: /api/errors/e0cb211cab1ddb08.
Report an issue: GitHub.