Provider '${provider}' cannot run inside a container yet (co

Error message

Provider '${provider}' cannot run inside a container yet (containerExec capability). Use provider claude, or run without --container.

What it means

A runtime backstop in the DAG executor: when a node turn is dispatched into a container (execContext.kind === 'container') but the resolved provider lacks the containerExec capability, the executor throws instead of silently downgrading the turn to the host. This is defense in depth alongside the run-start pre-scan, which hand-mirrors provider resolution and could drift.

Source

Thrown at packages/workflows/src/dag-executor.ts:1761

  // decided it keeps no node-level form, making it the single workflow-level
  // field with no per-node counterpart. There is deliberately no
  // ProviderCapabilities axis for one provider's one field.
  //
  // Reasoning depth is NOT in this category any more: the loader translates the
  // deprecated `modelReasoningEffort:` into `effort:`, so the executor sees one
  // provider-agnostic field and needs no Codex branch for it.
  const isCodex = provider === 'codex';

  // The one reasoning depth this node will run at, before any preset fallback.
  const declaredEffort = resolution.declaredEffort;

  // Runtime backstop for container dispatch: the run-start pre-scan
  // (collectContainerIncompatibleProviders) hand-mirrors this same provider
  // resolution, so it could drift. Re-check the RESOLVED provider here, at the
  // actual dispatch point, so a container turn can never reach a provider that
  // can't honor it — no silent host downgrade (defense in depth).
  if (execContext.kind === 'container' && !caps.containerExec) {
    throw new Error(
      `Provider '${provider}' cannot run inside a container yet (containerExec ` +
        'capability). Use provider claude, or run without --container.'
    );
  }

  // Capability warnings — inform users when features are unsupported
  const capChecks: [string, keyof ProviderCapabilities, boolean][] = [
    [
      'allowed_tools/denied_tools',
      'toolRestrictions',
      node.allowed_tools !== undefined || node.denied_tools !== undefined,
    ],
    ['hooks', 'hooks', node.hooks !== undefined],
    ['mcp', 'mcp', node.mcp !== undefined],
    ['skills', 'skills', node.skills !== undefined && node.skills.length > 0],
    ['agents', 'agents', node.agents !== undefined],
    ['effort', 'effortControl', declaredEffort !== undefined],
    ['thinking', 'thinkingControl', (node.thinking ?? workflowLevelOptions.thinking) !== undefined],

View on GitHub (pinned to 0773b97458)

Solutions

Switch that node's provider to claude (the container-capable provider).
Run without --container so nodes execute on the host.
Remove/adjust the provider on container-dispatched nodes, or wait for the provider to gain containerExec support.
If you believe the capability table is wrong, verify the provider's declared capabilities in the providers package.

Example fix

// before
archon run workflow.yaml --container   # node uses provider: codex
// after
provider: "claude"   # or drop --container

Defensive patterns

Strategy: validation

Validate before calling

if (runOpts.container && node.provider !== 'claude') {
  throw new Error(`Provider '${node.provider}' lacks containerExec; use claude or drop --container`);
}

Type guard

function supportsContainer(p: ProviderId, caps: ProviderCapabilities): boolean {
  return caps.containerExec === true;
}

Try / catch

try {
  await runWorkflow(wf, { container: true });
} catch (e) {
  if (String(e).includes('cannot run inside a container')) console.error('Use claude or run without --container');
  else throw e;
}

Prevention

Check the provider capability table before enabling --container.
Keep container and host dispatch node sets separate in workflow design.
Re-verify capabilities after provider upgrades.

When it happens

Trigger: Running with --container (or container exec context) while a node's resolved provider is one whose capabilities do not include containerExec — e.g. any provider other than claude under current capability tables.

Common situations: Mixing --container with a multi-provider workflow where one node uses a non-container-capable provider; the run-start pre-scan missed the node because resolution differed (drift) and this backstop fires at dispatch.

Related errors

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