AI Sandbox

Sandboxes

Harness adapters declare requires: [SandboxCapability]. chat() errors unless some middleware provides it — withSandbox(...) does. The adapter then runs the agent CLI inside the sandbox and streams its events back.

Setup — Claude Code in a Docker sandbox

import { chat, toServerSentEventsResponse } from '@tanstack/ai'
import { claudeCodeText } from '@tanstack/ai-claude-code'
import {
  createSecrets,
  defineSandbox,
  defineWorkspace,
  withSandbox,
} from '@tanstack/ai-sandbox'
import { dockerSandbox } from '@tanstack/ai-sandbox-docker'

const sandbox = defineSandbox({
  id: 'repo-agent',
  provider: dockerSandbox({ image: 'node:22' }),
  workspace: defineWorkspace({
    source: { type: 'git', url: 'https://github.com/owner/repo', ref: 'main' },
    packageManager: 'pnpm',
    setup: ['corepack enable', 'pnpm install'],
    scripts: { test: 'pnpm test' },
    secrets: createSecrets({
      ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY ?? '',
    }),
  }),
  lifecycle: { reuse: 'thread', snapshot: 'after-setup', keepAlive: '30m' },
})

export async function POST(request: Request) {
  const { threadId, messages } = await request.json()

  const stream = chat({
    threadId,
    adapter: claudeCodeText('sonnet'),
    messages,
    middleware: [withSandbox(sandbox)],
  })

  return toServerSentEventsResponse(stream)
}

Type-safe secrets

import { createSecrets, bearer } from '@tanstack/ai-sandbox'

const secrets = createSecrets({
  GH: process.env.GH_TOKEN ?? '',
  SENTRY: process.env.SENTRY_TOKEN ?? '',
})
// secrets.GH is a SecretRef — the underlying string is stored in a
// non-enumerable symbol-keyed registry and never logged, snapshotted,
// or written to the sandbox store.

Pass secrets to defineWorkspace({ secrets }) so skill and MCP projectors can resolve them. Use secret: secrets.GH in gitSkill for private-repo auth and secrets.GH / bearer(secrets.GH) in MCP header values:

• secrets.GH — resolves to the raw token value.
• bearer(secrets.GH) — resolves to "Bearer <value>".

Declarative provisioning (skills, plugins, MCP, instructions)

import {
  agentSkill,
  gitSkill,
  mcpSkill,
  fileSkill,
  bearer,
  createSecrets,
  defineWorkspace,
} from '@tanstack/ai-sandbox'

const secrets = createSecrets({ GH: process.env.GH_TOKEN ?? '' })

defineWorkspace({
  source: { type: 'git', url: 'https://github.com/owner/repo' },
  secrets,
  skills: [
    agentSkill('tanstack'), // named skill (no-op with warning on CLIs that lack the concept)
    gitSkill({
      repo: 'owner/private-skills',
      secret: secrets.GH, // resolved at bootstrap time, never stored
      // into: '/abs/path/inside/sandbox'  // optional; defaults to .tanstack-skills/<repo>
    }),
    mcpSkill('my-mcp', {
      url: 'https://mcp.example.com',
      headers: { Authorization: bearer(secrets.GH) },
    }),
    fileSkill({ path: '.hints.md', content: 'Prefer pnpm.' }),
  ],
  plugins: ['@anthropic/plugin-foo'], // no-op with warning on CLIs without a plugin concept
  instructions: 'Always run `pnpm test` before proposing a change.',
})

Each skill type is projected per harness (Claude Code → .mcp.json; Codex → .codex/config.toml; OpenCode → opencode.json). instructions is written as AGENTS.md at the workspace root; CLAUDE.md and GEMINI.md are created as symlinks (falling back to copies on symlink failure). Skills/plugins that a CLI lacks emit a console.warn and are skipped.

gitSkill into field: an absolute path inside the sandbox where the repo is cloned. Defaults to <root>/.tanstack-skills/<repo-basename>.

Fast init

Shallow clone (depth)

githubRepo / gitSource default to --depth 1 --single-branch. Override:

import { githubRepo, defineWorkspace } from '@tanstack/ai-sandbox'

defineWorkspace({ source: githubRepo({ repo: 'owner/app' }) }) // depth 1 (default)
defineWorkspace({ source: githubRepo({ repo: 'owner/app', depth: 10 }) }) // 10 commits
defineWorkspace({ source: githubRepo({ repo: 'owner/app', depth: 'full' }) }) // full history

Serial / parallel setup callback

setup accepts a plain Array<string> (all serial) or a callback that records serial and parallel groups over a persistent shell whose cwd/env carry over between serial steps:

import { githubRepo, defineWorkspace } from '@tanstack/ai-sandbox'

defineWorkspace({
  source: githubRepo({ repo: 'owner/app' }),
  setup: ({ serial, parallel }) => {
    serial('corepack enable')
    serial('pnpm install')
    parallel(['pnpm build', 'pnpm typecheck']) // concurrent; inherit cwd+env from shell
    serial('echo done')
  },
})

Snapshot-after-setup and snapshotMaxAge

When the provider supports snapshots, bootstrap takes one automatically after setup completes. Subsequent runs resume from the snapshot (skipping setup). Override or add a TTL:

import { defineSandbox } from '@tanstack/ai-sandbox'
import { dockerSandbox } from '@tanstack/ai-sandbox-docker'

const sandbox = defineSandbox({
  id: 'repo-agent',
  provider: dockerSandbox({ image: 'node:22' }),
  lifecycle: {
    snapshot: 'after-setup', // default when provider.capabilities().snapshots
    snapshotMaxAge: '24h', // re-create when the snapshot is older than this
  },
})

Providers without snapshot support skip the step silently.

Portable sandbox snapshots

Portable snapshots keep completed workspace files in application persistence. They are separate from provider-native bootstrap snapshots. Configure the middleware in this order, with the same persistence value in both places:

import { withPersistence } from '@tanstack/ai-persistence'
import {
  InMemorySandboxInstanceStore,
  memorySandboxSnapshots,
  withSandbox,
} from '@tanstack/ai-sandbox'
// Your `defineSandbox(...)` result.
import { sandbox } from './sandbox'

const instances = new InMemorySandboxInstanceStore()
const snapshots = await memorySandboxSnapshots({ sandbox, instances })

const middleware = [
  withPersistence(snapshots.persistence),
  withSandbox(sandbox, { instances, snapshots }),
]

Each successful terminal run saves regular files, empty directories, durable conversation data, and persisted thread artifacts. A later run restores the latest checkpoint only into a new private sandbox. A live resumed sandbox is never overwritten. The default policy excludes .git, node_modules, and .env* path segments at every depth. It excludes the exact projection marker only at the workspace root. It also excludes root CLAUDE.md and GEMINI.md, plus direct .claude/skills/<name>, .codex/skills/<name>, and .grok/skills/<name> paths. These exclusions use paths even for regular files or copies. If you pass only include or only redact, the default exclusions stay in place. If you pass exclude, that function replaces the default exclusions, except for exact projection-marker protection. Copy defaultSandboxSnapshotPolicy() first when you write exclude. Pass include and exclude functions on policy to store only some files, including one file. There is no save({ files }) list. See docs/sandbox/portable-snapshots-files.md. Resolved secrets are redacted before the data is stored. Symlinks, executables, and special filesystem entries fail the capture or restore. Each thread has one writer lease. Pause and detach release the lease without a partial checkpoint. Blob retention is manual because there is no automatic garbage collection yet.

Read these pages for the server-only setup:

• docs/sandbox/portable-snapshots.md
• docs/sandbox/portable-snapshots-configure.md
• docs/sandbox/portable-snapshots-save.md
• docs/sandbox/portable-snapshots-fork.md
• docs/sandbox/portable-snapshots-artifacts.md
• docs/sandbox/portable-snapshots-tools.md
• docs/sandbox/portable-snapshots-files.md
• docs/sandbox/portable-snapshots-safety.md

For a user-marked workspace state, call snapshots.save on the server. Bind sandbox and instances at create time, or pass them on save. The call needs threadId, runId, and a label. It requires a live reusable sandbox. reuse: 'none' cannot save a named checkpoint.

To branch from a selected checkpoint, call snapshots.fork with the thread id, checkpoint id, and destination thread id. The store must implement atomic forkFromCheckpoint. The destination thread must be empty. A fork copies the selected snapshot, not the latest snapshot.

To send a checkpoint artifact, call snapshots.readArtifact on the server. First authorize the caller for the supplied thread. The method makes sure that the checkpoint belongs to that thread, then returns its metadata and bytes. It does not authorize a caller or create an HTTP response.

For a SQLite checkpoint store, use one transaction for a checkpoint write, its head update, and every blob reference update. Use one transaction for a fork, including its copied conversation. A partial transaction breaks snapshot consistency.

Snapshot capture supports regular files and empty directories only. It excludes .git, node_modules, and .env* path segments at every depth. It excludes the exact projection marker only at the workspace root. It also excludes root CLAUDE.md and GEMINI.md, plus direct .claude/skills/<name>, .codex/skills/<name>, and .grok/skills/<name> paths. These exclusions use paths even for regular files or copies. If you pass only include or only redact, the default exclusions stay in place. If you pass exclude, that function replaces the default exclusions, except for exact projection-marker protection. It rejects symlinks, executable files, and special filesystem entries. Restore verifies the manifest and blobs before it changes a new private sandbox. It never writes into a live resumed sandbox.

Providers

• localProcessSandbox() — runs on the host (no isolation; dev loop only).
• dockerSandbox({ image }) — isolated container; snapshots, fork, resume-by-id.
• daytonaSandbox({ apiKey, snapshot, autoStopInterval, ephemeral }) — Daytona cloud sandbox; snapshots after setup; resume starts stopped or archived sandboxes. /workspace maps to /home/daytona/workspace. Setup that installs packages must use sudo -n (do not deny sudo *). See docs/sandbox/providers.md for network and secret injection details.

All implement the same SandboxHandle: fs (read/write/list/mkdir/remove/ rename/exists), git (clone/status/add/commit/push/pull/branch), process (exec + duplex spawn), ports.connect(port), env.set, optional snapshot()/fork(), destroy(). Providers advertise support via capabilities(); calling an unsupported optional method throws UnsupportedCapabilityError.

Policy

import { defineSandboxPolicy } from '@tanstack/ai-sandbox'

// Headless Grok Build / Codex: stay on auto-approve. Isolation is the
// outer sandbox (Docker, Daytona, …), not commands.deny on this policy.
const policy = defineSandboxPolicy({
  default: 'allow',
})
// pass to defineSandbox({ policy }); harness adapters map it to native permissions

Claude Code can use default: 'ask' plus allow/ask/deny lists. Use Claude Code when you need command-level deny. Provider privilege rules (non-root users, network block at create) live in docs/sandbox/providers.md.

Lifecycle & resume

reuse: 'thread' resumes one sandbox per threadId; the compound key folds in provider + workspace hash + tenant so changing the repo/setup/image starts fresh. Ensure order: resume running → restore snapshot → create + bootstrap.

Instance durability (durable resume)

Resume bookkeeping defaults to in-memory (single-process). For cross-process / multi-replica resume, implement a durable SandboxInstanceStore (BYO) and pass it as withSandbox(sandbox, { instances }). Pair multi-replica with a distributed lock: either withLocks from @tanstack/ai/locks (ordered before withSandbox) or the locks option.

import { chat, toServerSentEventsResponse } from '@tanstack/ai'
import { InMemoryLockStore, withLocks } from '@tanstack/ai/locks'
import { claudeCodeText } from '@tanstack/ai-claude-code'
import { withSandbox } from '@tanstack/ai-sandbox'
// Your `defineSandbox(...)` result.
import { sandbox } from './sandbox'
// Production: your BYO store — docs/sandbox/durability.md
import { instanceStore } from './sandbox-instance-store'

export async function POST(request: Request) {
  const { threadId, messages } = await request.json()

  const stream = chat({
    threadId,
    adapter: claudeCodeText('sonnet'),
    messages,
    middleware: [
      withLocks(new InMemoryLockStore()), // multi-replica: distributed lock
      withSandbox(sandbox, { instances: instanceStore }),
    ],
  })

  return toServerSentEventsResponse(stream)
}

The store option takes precedence over an ambient SandboxInstanceStoreCapability (provided by a platform layer via provideSandboxInstanceStore), which in turn beats the in-memory fallback.

Chat transcript durability (withPersistence) is independent — compose both when the app needs history and instance reuse. Prove adapters with runSandboxInstanceStoreConformance from @tanstack/ai-sandbox/testkit. Use defineSandboxInstanceStore({ get, upsert, delete }) for inline typing of a BYO store (same pattern as defineLock / defineMessageStore).

File-event hooks

Watch the workspace for create/change/delete events. Provider-agnostic: native fs.watch on local-process, a portable find poll on Docker/exec-only providers (no extra deps or image changes).

Declare hooks on defineSandbox({ hooks }) (sandbox-scoped) or on any chat middleware via the sandbox group (run-scoped):

import { defineSandbox, withSandbox } from '@tanstack/ai-sandbox'
// `defineChatMiddleware` is core's, not this package's — `@tanstack/ai-sandbox`
// consumes it too (see its own `src/middleware.ts`).
import { chat, defineChatMiddleware } from '@tanstack/ai'
import { claudeCodeText } from '@tanstack/ai-claude-code'
import { dockerSandbox } from '@tanstack/ai-sandbox-docker'
import { db } from './db'
import { metrics } from './metrics'

// Sandbox-scoped hooks (all optional):
const sandbox = defineSandbox({
  id: 'repo-agent',
  provider: dockerSandbox({ image: 'node:22' }),
  hooks: {
    onFile: (e) => console.log(e.type, e.path), // catch-all
    onFileCreate: (e) => console.log('created', e.path),
    onFileChange: (e) => console.log('changed', e.path),
    onFileDelete: (e) => console.log('deleted', e.path),
    onReady: (handle) => console.log('ready', handle.id),
    onError: (err) => console.error(err),
    onDestroy: () => console.log('destroyed'),
  },
  fileEvents: true, // default; set false to disable watching entirely
})

// Run-scoped hooks via chat middleware (ctx is ChatMiddlewareContext):
const auditMiddleware = defineChatMiddleware({
  name: 'audit',
  sandbox: {
    onFile: (ctx, e) => console.log(ctx.runId, e.type, e.path),
    onFileCreate: (ctx, e) => db.log({ run: ctx.runId, event: e }),
    onFileChange: (ctx, e) => metrics.increment('file.change'),
    onFileDelete: (ctx, e) => console.warn('deleted', e.path),
  },
})

// No extra middleware needed — sandbox.file CUSTOM events are emitted
// automatically. Read them from the stream:
const stream = chat({
  threadId: 'thread-1',
  adapter: claudeCodeText('sonnet'),
  messages: [{ role: 'user', content: 'Add a README.' }],
  middleware: [auditMiddleware, withSandbox(sandbox)],
})

for await (const chunk of stream) {
  if (chunk.type === 'CUSTOM' && chunk.name === 'sandbox.file') {
    const value = chunk.value
    if (
      value !== null &&
      typeof value === 'object' &&
      'type' in value &&
      'path' in value
    ) {
      console.log('file event', value) // { type, path, timestamp }
    }
  }
}

watchWorkspace() is available as a low-level building block for watching outside a chat() run:

import { watchWorkspace } from '@tanstack/ai-sandbox'
// Your `defineSandbox(...)` result.
import { sandbox } from './sandbox'

const handle = await sandbox.ensure({ threadId: 'thread-1', runId: 'run-1' })
const watcher = await watchWorkspace(handle, {
  onEvent: (e) => console.log(e.type, e.path),
  ignore: ['.git', 'node_modules'], // default
})
await watcher.stop()

Enable the sandbox debug category to log watcher start/stop, event dispatch, and lifecycle transitions:

import { chat, toServerSentEventsResponse } from '@tanstack/ai'
import { claudeCodeText } from '@tanstack/ai-claude-code'
import { withSandbox } from '@tanstack/ai-sandbox'
import { sandbox } from './sandbox'

export async function POST(request: Request) {
  const { threadId, messages } = await request.json()

  const stream = chat({
    threadId,
    adapter: claudeCodeText('sonnet'),
    messages,
    middleware: [withSandbox(sandbox)],
    debug: { sandbox: true }, // or debug: true to enable all categories
  })

  return toServerSentEventsResponse(stream)
}

Edge / serverless execution

A request-scoped Worker can't hold a multi-minute agent run open. The serverless/edge model splits this: a trigger starts the run and returns immediately, a durable orchestrator drives it, and clients tail from a resumable cursor.

Core primitives (@tanstack/ai-sandbox, transport- and runtime-agnostic):

• pipeToRunLog / RunController (the run driver), built on two of core's (@tanstack/ai) durable seams: a RunStore for the run's lifecycle record (the same store withPersistence uses for chat history) and a StreamDurability for its event log (memoryStream or durableStream). pipeToRunLog(stream, { runs, durability, runId, threadId, signal, logger }) pumps a chat() stream into both and is total: every store/event-log call is individually guarded, so it never throws and never rejects. A thrown stream error becomes a terminal RUN_ERROR event plus the record's error, so a detached client always observes failures, and a failing store write or a failing durability close is recorded through the optional logger (same logger?.errors(...) contract core uses) rather than silently absorbed. threadId is required. RunController wraps a fixed RunDeps = { runs, durability, logger? }, where durability is a per-run factory (runId) => StreamDurability, not an instance:

  import { InMemoryRunStore, memoryStream } from '@tanstack/ai'
  import { RunController } from '@tanstack/ai-sandbox'
  import type { StreamChunk } from '@tanstack/ai'
  
  const runs = new InMemoryRunStore()
  
  export async function driveOne(
    request: Request,
    runId: string,
    threadId: string,
    stream: AsyncIterable<StreamChunk>,
  ): Promise<void> {
    const controller = new RunController({
      runs,
      // A per-run FACTORY. A `StreamDurability` is bound to ONE run, so the log
      // is resolved FROM the runId rather than handed in pre-bound. Whatever you
      // pass MUST return the same instance for the same runId within a process,
      // or `snapshot()` will not see this host's own appends. `memoryStream`
      // keys its log by the run the request names, so every call for one run
      // shares one log; swap in `durableStream(request, options)` in production.
      durability: () => memoryStream(request),
    })
  
    const handle = controller.start({ runId, threadId, stream })
    // handle.runId, handle.done (resolves with the terminal RunRecord)
  
    // `attach` takes the runId FIRST, because the log it reads is per-run.
    // fromOffset is an opaque string the durability adapter produced; for
    // memoryStream, '-1' replays from the start. The third `signal` argument is
    // optional and stops tailing when it aborts.
    for await (const { offset, chunk } of controller.attach(runId, '-1')) {
      console.log(offset, chunk.type)
    }
  
    await handle.done
    await controller.drain() // await every in-flight run, e.g. inside waitUntil
  }
  

  Terminal statuses are 'completed' | 'failed' | 'aborted' (core's TerminalRunStatus); a run may also be 'running' or 'interrupted' (RunStatus). Because the log is resolved from the runId, a RunController is safe for concurrent runs: each run appends to its own log and no run's close() terminalizes another's. Two failures that a single pre-bound instance used to make reachable are now unrepresentable — writing the lifecycle record under one id and the events under another, and parallel runs interleaving chunks into one log. Do not hand back the same StreamDurability for every runId to "simplify" the factory; that reintroduces both.

  For a production takeover, do not drive RunController / pipeToRunLog by hand — use sandboxRunDriver (see Takeover), which owns the claim, the epoch fence, and the quiescence gate.

• Transport-agnostic tool-bridge — createToolBridgeCore + handleBridgeJsonRpc are the portable core; startHostToolBridge is the node:http host transport. The ToolBridgeProvisioner capability injects the transport, so an edge orchestrator serves the same core from its own fetch handler (no raw TCP listener). Default = host transport.

• Co-located host-tool seam — toolDescriptors / remoteToolStubs / httpRemoteToolExecutor (container side) + executeHostTool (orchestrator side): only chat()-tool EXECUTION crosses the container→orchestrator boundary, not the whole MCP protocol.

• SandboxCapabilities.writableStdin — false for providers (e.g. Cloudflare) with no writable host→process stdin; stdin-fed harnesses then deliver the prompt via a file + in-shell redirection (claude -p … < file).

Cloudflare runtime (@tanstack/ai-sandbox-cloudflare):

• createCloudflareSandboxAgent(config) → { Coordinator, Sandbox, worker } — an app's worker.ts is one configured call plus the wrangler-required DO re-exports. Two models via mode: do-drives (the DO runs chat()) and colocated (harness + bridge run in-container; the DO is a thin coordinator, pair with runInContainerHarness from /runner).
• DurableObjectRunEventLog mirrors InMemoryRunEventLog (both live in @tanstack/ai-sandbox-cloudflare, exported from its /agent entry) over DO storage; timingSafeBearerEqualWeb is the Web-Crypto constant-time bearer check. That package's own RunStatus, TerminalRunStatus, RunRecord, and RunError describe its event-log vocabulary, which is deliberately distinct from core's run-lifecycle types of the same names; the /agent entry re-exports them under a Legacy prefix (LegacyRunStatus, LegacyTerminalRunStatus, LegacyRunRecord, LegacyRunError) so an app can import both this package's run driver and the Cloudflare event log without a name collision. RunEventLog, RunEvent, and RunEventLogReadOptions have no equivalent in core and keep their plain names.

Durable runs (the run journal)

A harness adapter's agent CLI (Claude Code, Codex, …) writes its NDJSON stdout into a run journal instead of a pipe the host holds open: a shell redirect appends every line to /tmp/tanstack-runs/<runId>.ndjson inside the sandbox (stderr goes to a <runId>.err sidecar, never mixed in), so the host can return without holding a live process handle, and a reader replays the same file from byte 0 at any point, including after the original host has died.

import { spawnNdjson } from '@tanstack/ai-sandbox'
import type { SandboxHandle } from '@tanstack/ai-sandbox'

export async function runAgent(handle: SandboxHandle, runId: string) {
  const agentCommand = 'claude -p --output-format stream-json'
  for await (const event of spawnNdjson(handle, agentCommand, {
    cwd: '/workspace',
    journal: { runId }, // durability is opt-in: pass `journal` to route through it
  })) {
    // parsed NDJSON objects, translated by the harness adapter as usual
    console.log(event)
  }
}

A runId MUST be unique per run. The journal is append-only by design (a takeover needs the prefix a previous host already wrote to still be there), so reusing a runId appends to the previous run's journal file. A reader stops at the FIRST {"__exit":N} sentinel it encounters, which is the earlier run's, so the new run appears to emit nothing, or to fail with the previous run's exit code. Uniqueness is therefore the caller's job and is deliberately not enforced — refusing to append would break the append-only property a takeover depends on.

Absence, unlike reuse, IS enforced. Every harness adapter routes through resolveDurableRunId(options.runId, { durable, adapter, fallback }), which throws DurableRunIdRequiredError when sandbox durability is wired and no runId was passed — a generated id is never minted for a durable run, not even one that is discarded, because no successor host could recompute its journal path. The fallback() to a generated id survives only for non-durable runs, where several chat() paths legitimately pass runId as a conditional spread. The journaling adapters are Claude Code, Codex, and Grok Build; ACP and OpenCode do not journal and pass durable: false, so they keep the fallback unconditionally today and inherit the enforcement automatically if either gains journaling.

Reading strategy

readJournal (and spawnNdjson's journal path, via readJournalNdjson) picks one of two strategies from the sandbox's advertised capabilities, never from the provider's name:

• follow (tail -f, started with handle.process.spawn), when capabilities.backgroundProcesses && capabilities.killableProcesses are both true. It streams with no polling cost and is stopped by killing the tail when the consumer stops reading.
• bounded poll (repeated bounded exec reads, DEFAULT_JOURNAL_POLL_MS, 250ms) otherwise. killableProcesses is false for a provider like Cloudflare, whose kill() is a documented no-op and whose Workers RPC cannot serialize an AbortSignal across the boundary, so a tail -f started there could never be stopped and the poll path is used instead.

The bounded read (journalReadCommand) base64-frames its output, because exec closes the encoder's stdin, which flushes it, so the whole frame arrives as one complete result. The follow path (journalFollowCommand) does not base64-frame its output: base64 fully buffers its stdout when that stdout is not a tty, so tail -f file | base64 would emit nothing until the libc stdio buffer fills or tail -f's stdin closes, and that stdin never closes until the reader kills it, at which point the consumer has already stopped waiting for bytes. Dropping the frame on the follow path is safe because the journal is line-delimited JSON and every provider already decodes stdout text on this path the same way it decodes an agent's own stdout.

Alignment: replaying without duplicating

alignToStoredLog reads a run's already-stored event log with durability.snapshot() (a bounded, point-in-time read; never read(), which tails and never resolves against a log a dead producer never closed), compares each replayed chunk against the stored one by chunkFingerprint, and forwards only the remainder past what is already stored. Downstream, that remainder is always passed to append, never upsert: the journal path only ever appends, because deciding the append point is exactly what alignment does. A replayed chunk that does not match the stored chunk at the same index throws JournalReplayDivergedError rather than forwarding data that might be corrupt.

Message ids on the journaled path come from createRunScopedIdGen(runId), a per-run counter (<runId>-0, <runId>-1, …) with no clock and no randomness, wired as harness translators' genId, so re-translating the same journal bytes twice reproduces the same ids. chunkFingerprint excludes only the timestamp field (wall-clock, unreproducible) from the comparison; everything else, including nested tool-call arguments, participates.

Determinism is translator-level only. On ai-claude-code and ai-codex, mergeChunkStreams(translated, channel.stream) splices host-tool-bridge events from a live tool execution into the middle of the stream; those events do not occur again on replay. A run that used a bridged tool can still diverge on replay for that reason: alignment guarantees reproducibility of the translation step, not of everything that can happen during a run.

Cleanup

Once a run reaches its {"__exit":N} sentinel, both journal files are deleted. A run that terminates while detached (no host reading its journal) has no reader to observe the sentinel, so nothing deletes its journal on the run's own path. pruneJournals bounds that: it walks the journal directory, asks the run store about each runId it decodes, deletes only the journals whose runs are terminal, and keeps everything it cannot prove dead (non-terminal, undecodable, or too young to be an orphan). It runs from a cron the application schedules, not from a run, so an abandoned journal survives until that sweep — this journal, reader, and alignment primitive do not clean it up themselves.

The journal, the reader, and alignToStoredLog are the primitives a takeover is built from. sandboxRunDriver is what drives one — see the next section.

Takeover: detached runs and single-writer safety

A tab does not last ten minutes; a sandboxed coding agent does. Without durability wired, withSandbox's abort path destroys the sandbox on every abort, deliberately — closing the agent's IO stream does not kill the agent process (a Docker exec survives its client), so destroying the container is the only reliable way to stop it burning tokens. Correct for a cancel, ruinous for a refresh.

Durability is ONE opt-in, not two

withSandbox(sandbox, { runs, durability }). A run is durable only when both are present: a record with no event log cannot be replayed, and a log with no record cannot be found, claimed, or reaped. There is no half-configured state — pass one and you silently get exactly today's behavior, with no warning, because you have not asked for durability. This is the single easiest way to believe you shipped durable runs and have shipped nothing.

Pass the same RunStore chat persistence uses (persistence.stores.runs), and hand the same StreamDurability instance to both withSandbox and the transport, so one record and one log describe the run.

import { memoryStream, toServerSentEventsResponse } from '@tanstack/ai'
import { withSandbox } from '@tanstack/ai-sandbox'
import type { AnyChatMiddleware, RunStore } from '@tanstack/ai'
import type { SandboxDefinition } from '@tanstack/ai-sandbox'

export function durableSandboxMiddleware(
  request: Request,
  sandbox: SandboxDefinition,
  runs: RunStore,
): { middleware: AnyChatMiddleware; adapter: ReturnType<typeof memoryStream> } {
  // ONE adapter instance, handed to both the middleware and the transport.
  const adapter = memoryStream(request)
  return {
    adapter,
    middleware: withSandbox(sandbox, {
      runs,
      durability: { adapter },
    }),
  }
}
// …then: toServerSentEventsResponse(stream, { durability: { adapter } })

runId is also required for a durable run: chatStream throws DurableRunIdRequiredError when none is passed, because the journal path and the deterministic id generator are both derived from it and a successor host can only resume a run whose runId it can recompute.

Detach vs cancel — intent NEVER comes from the disconnect

A user pressing Stop and a user closing the tab produce the identical connection close. There is nothing in the disconnect to tell them apart, so never try. Intent arrives out of band, and there are exactly two bands, either of which is authoritative:

1. Durable — requestRunCancel(runs, runId) records cancelRequested on the run record. This is the only channel that reaches a run being driven by a different host than the one the cancel landed on, which is the normal case for a detached run.
2. In-process — abort the run's own AbortController with RUN_CANCEL_REASON. Core reads that reason back into AbortInfo, so AbortInfo.cancelRequested is true for that abort and false for a plain disconnect. Fast path only.

A cancel endpoint should do both. requestRunCancel deliberately writes no status: recording intent is not the same as the run having stopped, and only the driver knows when the agent is dead and the sandbox is gone.

import { RUN_CANCEL_REASON, requestRunCancel } from '@tanstack/ai'
import type { RunStore } from '@tanstack/ai'

/** Runs THIS process drives. A run driven by another replica is absent here. */
const driving = new Map<string, AbortController>()

export async function cancelRun(
  runs: RunStore,
  threadId: string,
): Promise<void> {
  const active = await runs.findActiveRun(threadId)
  if (!active) return
  // Band 1: durable, so a remote driver observes it on its next teardown.
  await requestRunCancel(runs, active.runId)
  // Band 2: in-process, so a co-located driver stops immediately.
  driving.get(active.runId)?.abort(RUN_CANCEL_REASON)
}

On the client, chat.stop() alone is not a cancel. It aborts a local AbortController and sends the server nothing, which on a durable run is indistinguishable from a refresh — so the agent keeps running and keeps spending tokens with nobody watching. Call a cancel endpoint too.

What each path writes: a disconnect on a durable run with detachOnDisconnect on and no cancel recorded keeps the sandbox and writes detachedSince + sandboxKey, while withPersistence writes nothing (the record stays 'running'). A cancel in either band destroys the sandbox regardless of destroyOnComplete, and withPersistence writes 'aborted'. keepAlive / destroyOnComplete: false govern successful completion only — they never keep a sandbox alive through a cancel.

sandboxRunDriver — the supported way to drive a resumed run

Takeover happens in the GET handler that already serves resumes. Add a driver and the same request that replays the log also claims the run and keeps driving it. Do not hand-roll this. sandboxRunDriver owns the claim, the epoch fencing, and the quiescence gate; a consumer wiring pipeToRunLog directly is re-implementing exactly the seam that produced this phase's duplicate-write and false-terminal-write bugs.

import { memoryStream, resumeServerSentEventsResponse } from '@tanstack/ai'
import { sandboxRunDriver } from '@tanstack/ai-sandbox'
import type { RunStore, StreamChunk } from '@tanstack/ai'
import type { LockStore } from '@tanstack/ai/locks'

/**
 * The claim hands `drive` an `AbortSignal` that fires the moment this host loses
 * ownership; `chat()` takes an `AbortController`. Mirror one onto the other, or
 * a lost claim never stops the drive.
 */
export function controllerFor(signal: AbortSignal): AbortController {
  const controller = new AbortController()
  const abort = (): void => controller.abort(signal.reason)
  if (signal.aborted) abort()
  else signal.addEventListener('abort', abort, { once: true })
  return controller
}

export function takeoverResponse(
  request: Request,
  runs: RunStore,
  locks: LockStore,
  drive: (input: {
    runId: string
    threadId: string
    signal: AbortSignal
  }) => AsyncIterable<StreamChunk>,
): Response {
  return resumeServerSentEventsResponse({
    adapter: memoryStream(request),
    driver: sandboxRunDriver({
      request,
      runs,
      locks,
      // Per-run factory, same shape as `RunDeps.durability`.
      durability: () => memoryStream(request),
      drive,
      // Serverless: pass `waitUntil: (p) => ctx.waitUntil(p)` to keep the
      // background drive alive. `fenceQuietMs` overrides the quiescence window.
    }),
  })
}

Inside drive, run chat() with abortController: controllerFor(input.signal) and withSandbox(sandbox, { runs, durability: { adapter, attach: true } }). attach: true is the whole difference — the harness tails the run's EXISTING journal instead of starting a second agent. It belongs there and never on chat() (core has no sandbox vocabulary), and it is set only by an attach route, never by a POST handler. Load the thread from the message store: the client sent no history because it is reconnecting, not asking a question — and pass the run record's threadId. Forget it and the attach refuses up front with DurableThreadIdRequiredError rather than failing mid-stream: every emitted chunk carries threadId, so a generated one differs from the stored log in its very first chunk. resolveDurableThreadId throws only in the durable-AND- attaching quadrant — a durable fresh run legitimately mints its threadId, since it is the run that establishes it. JournalReplayThreadIdMismatchError is still what surfaces if a mismatched threadId reaches alignToStoredLog by some other route; sandboxRunDriver itself forwards active.threadId into drive({ runId, threadId, signal }), so the remaining gap is application drive code that does not pass it on to chat().

The response is byte-identical whether or not you pass driver: it still replays from the durability log. The drive runs beside it, appending to the producer-side log, and the response tails what lands. Everything is total by construction — no run id, no record, an already-terminal record, another host holding the claim, or a throwing drive all resolve to "serve the log, drive nothing", logged server-side.

Branchable failures, all barrel-exported:

import {
  RunClaimLostError,
  RunClaimNotAcquiredError,
  RunDriverPipeOutsideClaimError,
} from '@tanstack/ai-sandbox'

export function describeDriveFailure(error: unknown): string {
  if (error instanceof RunClaimNotAcquiredError) {
    // 'terminal' | 'unknown' | 'superseded' — an ordinary contended takeover.
    return `not driving ${error.runId}: ${error.reason}`
  }
  if (error instanceof RunClaimLostError) {
    return `superseded mid-drive at epoch ${error.heldEpoch}`
  }
  if (error instanceof RunDriverPipeOutsideClaimError) {
    // Programming error: the options object was taken apart and `pipe` called
    // outside `claim`, so there is no epoch to fence with.
    return `run ${error.runId}: pipe ran outside its claim`
  }
  throw error
}

The first two are normal outcomes of a contended takeover and resumeServerSentEventsResponse already swallows both — expect them in logs, not in responses.

Single-writer safety: BOTH seams are fenced

Only one host may write a run. The client has no safety net below its offset de-dup: if two hosts each snapshot the log, compute a "remainder", and append it, the same logical chunk lands twice under two different offsets, looks new, and the stream processor applies text and tool-argument deltas unconditionally — doubled prose and {"a":1}{"a":1} tool arguments. Takeover is by definition two hosts wanting one run, so the exclusion has to be real. Three layers, all wired by sandboxRunDriver: a per-run lease (LockStore.withLock around the whole drive), an epoch (RunRecord.driverEpoch, bumped by each successful claim and re-read before appends), and quiescence (the successor waits for the stored log to stop growing before its first append; DEFAULT_FENCE_QUIET_MS = 5s, override with fenceQuietMs).

A run's facts live in two places, and both are fenced. This is the part a reader gets half-right and then builds a broken poller on:

• **The

…(truncated)