paperclipai/paperclip · error · Error

workspace_durable_seed_missing

workspace_durable_seed_missing

Error message

workspace_durable_seed_missing

What it means

Guard in prepareSandboxManagedRuntime: the spec references a durable workspace seed archive, but the expected seed file is not present at runtime root before the workspace tarballs are built/extracted. The durable seed that should seed the workspace is missing entirely (as opposed to corrupted, which raises workspace_durable_seed_digest_mismatch).

Source

Thrown at packages/adapter-utils/src/sandbox-managed-runtime.ts:1096

  // Optional host span runner for the workspace tarball build. When present, the
  // host builds both workspace tarballs inside one span named `pack`, so the
  // host pack time is visible under the `stage.sync` step. The default is a
  // no-op that keeps the current behavior and control flow. A throwing runner
  // never changes control flow (see `createRuntimeSpanRunner`).
  runtimeSpan?: RuntimeSpanRunner;
}): Promise<PreparedSandboxManagedRuntime> {
  const workspaceRemoteDir = input.workspaceRemoteDir ?? input.spec.remoteCwd;
  const runtimeRootDir = path.posix.join(workspaceRemoteDir, ".paperclip-runtime", input.adapterKey);
  const syncWorkspace = input.syncWorkspace !== false;
  const workspaceInboundMode = input.workspaceInboundMode ?? "host_current";
  const stageWorkspace =
    syncWorkspace && workspaceInboundMode !== "adopt_remote";
  const prepareWorkspaceSeed =
    syncWorkspace &&
    workspaceInboundMode === "adopt_remote" &&
    input.workspaceDurableSeed !== undefined;
  if (workspaceInboundMode === "durable_seed" && !input.workspaceDurableSeed) {
    throw new Error("workspace_durable_seed_missing");
  }

  // Reject any unsafe asset key before an archive path or an asset directory is
  // built from it. This runs before the git snapshot work so a bad key fails fast.
  for (const asset of input.assets ?? []) {
    assertRuntimeAssetKeyIsSafe(asset.key);
  }

  // Wrap a host-side staging sub-step or one scheduler task in its own span when
  // the caller injects a runtime span runner. The runner defaults to a no-op, so
  // a caller with no injected runner keeps the current control flow, and a
  // throwing runner never changes it (see `createRuntimeSpanRunner`). The two
  // pre-`pack` operations — the git enumeration and the baseline content-hash
  // walk — parent under the `stage.sync` step, so they stop showing up as a
  // hidden gap at the head of the step. Each inbound task (`stage.workspace`,
  // `stage.asset.<key>`, `stage.project.<id>`) and each outbound restore task
  // (`restore.workspace`, `restore.asset.<key>`) opens its own span, so two
  // concurrent tasks produce overlapping spans and the `pack` span nests under

View on GitHub (pinned to 01ad858492)

Solutions

  1. Regenerate the durable seed archive for the workspace and re-run the prepare
  2. Fix the seed path in the runtime spec if it points at the wrong location
  3. Fall back to a full workspace sync (non-seeded) if the seed is optional for the run
Defensive patterns

Strategy: fallback

When it happens

Trigger: Thrown at packages/adapter-utils/src/sandbox-managed-runtime.ts:1096 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10). Data as JSON: /api/errors/e4a1d902a45a4ca9. Report an issue: GitHub.