workflow.container_resume_without_backend

workflow.container_resume_without_backend

Error message

Run '${preCreatedRun.id}' executed inside an isolation container. Resume it from the CLI in the same project (`archon workflow approve/reject/resume <id>`), where the container is rediscovered — chat/web resume cannot rewire it.

What it means

A workflow run that executed inside a container-isolation context can only be resumed where the isolation container can be rediscovered — which only the CLI run in the same project can do. When a resume/approve/reject arrives through a path without a container backend (containerCtx is null) for a run marked metadata.isolation === 'container', the executor refuses: it warns the user, fails the run, and returns failure rather than resuming outside its container.

Source

Thrown at packages/workflows/src/executor.ts:1866

      throw new Error(
        `Cannot resume workflow run '${preCreatedRun.id}' with session state from run '${foreignPriorNodeSession.workflow_run_id}' (node '${foreignPriorNodeSession.node_id}')`
      );
    }
  }

  // Guard: a container run MUST be resumed with its container rewired (the CLI does
  // this via backend.resumeEnv, threading a `container` context). A resume that
  // reaches here for a container run WITHOUT that context — e.g. approving a
  // --container run from chat/web, which has no docker backend wired — would run
  // host-side and SILENTLY skip the write-back apply, losing the approved changes.
  // Fail loudly and point at the CLI instead; the run stays resumable (failed) so
  // the CLI can rediscover the container and apply.
  if (preCreatedRun?.metadata?.isolation === 'container' && !containerCtx) {
    const msg =
      `Run '${preCreatedRun.id}' executed inside an isolation container. Resume it from the ` +
      'CLI in the same project (`archon workflow approve/reject/resume <id>`), where the ' +
      'container is rediscovered — chat/web resume cannot rewire it.';
    getLog().warn({ workflowRunId: preCreatedRun.id }, 'workflow.container_resume_without_backend');
    await safeSendMessage(platform, conversationId, `⚠️ ${msg}`);
    await requireTerminalStatusWrite(deps.store.failWorkflowRun(preCreatedRun.id, msg), {
      workflowRunId: preCreatedRun.id,
      site: 'workflow.container_resume_guard_fail_failed',
    });
    return { success: false, workflowRunId: preCreatedRun.id, error: msg };
  }

  let runConfigMetadata: WorkflowRunConfigMetadata | undefined;
  let effectiveRunConfig: WorkflowRunConfigInput | undefined;
  try {
    if (isContinuation) {
      runConfigMetadata = readWorkflowRunConfigMetadata(preCreatedRun.metadata);
      if (runConfigMetadata) {
        if (!deps.unsealRunConfig) {
          throw new Error('This Archon build cannot restore persisted workflow run config.');
        }
        effectiveRunConfig = {

View on GitHub (pinned to 0773b97458)

Solutions

Run `archon workflow approve/reject/resume <runId>` from the CLI in the same project directory where the run originally executed so the container is rediscovered.
Verify the isolation container still exists and is reachable from that project; restore/recreate it if removed.
If the container is unrecoverable, explicitly fail or cancel the run and start a new run.
Treat container-isolated runs as CLI-only for lifecycle operations; hide or redirect chat/web resume actions for them.

Example fix

// before: approving from web/chat -> run fails with this guard
// after: resume from the original project via CLI
$ cd /path/to/original/project
$ archon workflow approve <runId>

Defensive patterns

Strategy: validation

Validate before calling

// Check isolation metadata and choose the right channel before resuming:
if (run.metadata?.isolation === 'container' && !isCliResume) {
  throw new Error('Container-isolated runs must be resumed via CLI in the original project');
}

Type guard

function requiresCliResume(run: { metadata?: { isolation?: string } }): boolean {
  return run.metadata?.isolation === 'container';
}

Try / catch

try {
  await resumeRun(runId);
} catch (e) {
  if (String(e?.message ?? e).includes('isolation container')) {
    console.error('Resume via: archon workflow resume ' + runId + ' (from the original project directory)');
  } else {
    throw e;
  }
}

Prevention

Only approve/resume container-isolated runs from the CLI in the project that owns the container.
Keep the isolation container alive until all its paused runs are terminal.
Surface isolation metadata in chat/web UIs and disable or redirect resume actions for container runs.
Don't operate on a run from a different project directory than where it executed.

When it happens

Trigger: Attempting resume/approve/reject of a run whose metadata.isolation === 'container' via chat/web platform paths (or any resume without containerCtx) at executor.ts:1866, or running the CLI resume from a different project directory where the container cannot be rediscovered.

Common situations: Operator approves a paused container-isolated workflow from Slack/Discord or the Web UI; CLI resume executed from the wrong working directory; the isolation container was deleted so even a correct-channel resume cannot rediscover it.

Related errors

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