Description

ensureDockerImage() now throws when DEFAULT_SANDBOX_IMAGE is missing instead of pulling/tagging a fallback.

This becomes an availability/DoS risk because the error propagates to sandbox initialization and can terminate an embedded run:

• Input/condition: Docker sandboxing enabled + default image not present on host
• Throw site: ensureDockerImage(DEFAULT_SANDBOX_IMAGE)
• Propagation: createSandboxContainer() → ensureSandboxContainer() → createDockerSandboxBackend() → resolveSandboxContext()
• Upstream handling: at least one caller (runEmbeddedAttempt) awaits resolveSandboxContext() outside its surrounding try { ... } catch { ... }, so the exception can abort the run and potentially cause repeated restart loops depending on deployment.

Vulnerable code:

if (image === DEFAULT_SANDBOX_IMAGE) {
  throw new Error(
    `Sandbox image not found: ${image}. Build it with scripts/sandbox-setup.sh before enabling Docker sandboxing. ...`,
  );
}

Recommendation

Handle missing images gracefully at the sandbox-entry boundary so a missing Docker image does not crash the whole run.

Options:

1. Catch and disable sandboxing in the caller that creates the sandbox context (preferred for resiliency):

let sandbox: SandboxContext | null = null;
try {
  sandbox = await resolveSandboxContext({ config, sessionKey, workspaceDir });
} catch (e) {
  const msg = e instanceof Error ? e.message : String(e);
  log.error(`Sandbox unavailable; continuing without sandbox: ${msg}`);
  sandbox = null;
}

2. Alternatively, add an allowFailure/enabled toggle to sandbox resolution so callers can opt into “best-effort” sandboxing.

Also ensure any process supervisor does not infinitely restart on this configuration error (surface a clear, actionable message and fail fast only in CLI commands that explicitly require sandboxing).