Making Every Coding Agent Harness Durable

From Local to Cloud: The Durability Challenge for Coding Agent Harnesses

Developers have long been accustomed to running coding agents locally through harnesses like Pi and Claude Code. These tools perform reliably in day-to-day code generation, but running them around the clock requires keeping your computer powered on and awake—giving rise to the "laptop lid closed" meme and surging demand for Mac minis.

Now, coding agent harnesses are moving to the cloud, where closing the lid is no longer a problem. But running in the cloud introduces new complexity: local harnesses have direct, persistent disk access to workspaces and session history, so after an interruption a simple prompt is enough to resume. On a cloud VM, however, nothing automatically records which model and tool calls have completed, and interrupted turns can't be recovered after a crash—a single failed call or network error means lost work. Not every agent task needs a sandbox, either: database queries and API calls can run safely inside a function, which also means the credentials they need never have to enter a sandbox.

durable-harness: Injecting Durability into Any Harness

Vercel previously built eve and fx to be durable by design in the cloud. Now durable-harness extends that durability to any harness, including Pi, OpenCode, Codex, and Claude Code. It uses the same mechanisms that power the Workflow SDK to withstand crashes and function timeouts.

With durable-harness, developers can:

• Run any of the above harnesses durably on Vercel
• Self-host harnesses using their own Postgres instance
• Make local harness workflows durable
• Build their own durable harnesses

Its core design revolves around a "log and queue" pattern. durable-harness is a set of adapters and utilities that let existing harnesses store sessions in a World (the Workflow SDK's durable backend). It records intent before a model or tool call runs, and records the result once the call completes. The turn itself is backed by a queue message: if the function dies, the queue hands the turn to a new function, which reads the log and continues from the breakpoint.

Workflow SDK is Vercel's toolkit for building durable, resumable workflows. It breaks long-running tasks into replayable steps, each recording its inputs and outputs to durable storage. When a function is interrupted by a timeout or crash, the SDK can continue from the last completed step instead of starting over. The core abstraction of the Workflow SDK is the World, which encapsulates three capabilities—log, queue, and stream—decoupling the workflow engine from any specific storage backend. durable-harness reuses this underlying machinery to extend durability from natively supported workflows to third-party coding agent harnesses.

The Mechanics of Crash Recovery

Take the example of a coding agent adding a pricing page to an existing app: the agent reads the existing page, writes the new page, opens a pull request, and waits for CI before reporting. What happens if the function times out while CI is still running?

Without durability, the agent stops until manually restarted, and completed work is needlessly repeated. With durable-harness, a new function reads the completed results from the log and resumes the turn. If the browser disconnects, the agent keeps running, and on reconnect it catches up from the log.

After a crash, the log clearly records which calls completed, which are running, and which never started. Completed calls never run again, because their results are read from the log—meaning you don't pay twice for the tokens of a finished model call. The model remembers previous calls instead of repeating them. Interrupted tools marked replay: 'safe' are re-run; other tools are returned to the model as "may have run," and the model decides whether to check.

For harnesses that keep their own session files (such as Claude Code's transcript, Codex's rollout, or OpenCode's event store), every record is mirrored into the log, from which a new function or Sandbox can rebuild them.

Idempotency is the key concept for understanding crash recovery. An operation is idempotent if running it multiple times has the same effect as running it once. During an agent run, model calls are typically not idempotent—repeating one consumes extra tokens and may produce a different result—whereas query-like tools (such as reading a file or searching) are often idempotent. durable-harness's replay: 'safe' flag essentially declares that a tool is idempotent and safe to re-run; 'never' marks non-idempotent operations (such as refunds) that must never be repeated. The pattern of logging "intent" and "result" is a common way to achieve exactly-once semantics: write the intent before executing, write the result afterward, and on recovery use the log to determine which steps have already completed.

Safety Policies for Tools and the Filesystem

Every tool must declare its behavior when interrupted by a crash. 'safe' tools (such as lookups) can run again; 'never' tools (such as refunds) never run twice—the model is told the call may have already happened so it can check before retrying.

For the filesystem, durable-harness offers three options:

• virtual(): files are stored in the session log with a bash-compatible shell, no access to the function's files or network—suited to short tasks and small workspaces
• virtual({ durable: false }): files are held in memory for draft work and cleared at the end of each turn
• sandbox(): gives the session its own Vercel Sandbox, with /workspace on Drive, which is more durable than both the sandbox and the function—suited to real projects and long-running work

Claude Code and Codex always run in a Vercel Sandbox, because they need a real shell and filesystem and aren't suited to multi-tenant use.

Vercel Sandbox is an isolated, ephemeral compute environment that gives each session its own filesystem and shell, segregated from the host function and other tenants. It's suited to agent tasks that need a real filesystem, arbitrary command execution, or network access, but it has some startup latency and a limited default lifetime. durable-harness places /workspace on Drive storage, which is more durable than the sandbox itself, meaning that even after a sandbox instance is reclaimed or rebuilt, the workspace files persist and a new sandbox can mount the same Drive and continue. This separation of ephemeral compute from durable storage is the infrastructure prerequisite for long-running, crash-recoverable cloud agents.

The World Interface: Write Once, Run Anywhere

A durable agent needs a log of every step, a way to resume a turn after the process dies, and a stream for observers. The Workflow SDK encapsulates all three behind a single interface, the World. durable-harness writes to that interface, so the same agent can move from one World to another without code changes: Vercel World on Vercel, local files during development, or Postgres, MongoDB, Redis, or Turso when self-hosting.

Two environment variables are all it takes to move every agent using durable-harness to Postgres:

WORKFLOW_TARGET_WORLD="@workflow/world-postgres"
WORKFLOW_POSTGRES_URL="postgres://user:password@host:5432/database"

In Vercel's Agent Runs tab, a trace is shown for every session, including every model call and tool call. Turns that resume after a crash appear in the same trace, clearly showing where the turn stopped and where it continued.

Postgres, MongoDB, Redis, and Turso here all serve as storage implementations of the World interface. Postgres and MongoDB are general-purpose databases offering transactional and durability guarantees, well suited to production self-hosting; Redis is an in-memory key-value store with extremely fast reads and writes but durability that depends on configuration, suited to latency-sensitive scenarios; Turso is an edge database built on SQLite, lightweight and supporting embedded deployment. Because durable-harness depends only on the World abstraction, switching backends requires nothing more than changing the WORKFLOW_TARGET_WORLD environment variable and the corresponding connection string—the agent code stays untouched. This portability avoids vendor lock-in and lets local development (file backend) and cloud production (Postgres, etc.) share the same code path.

Documents: A New Carrier for Session State

Some state belongs to the session but not to the conversation—for example, a to-do list, a plan, or a form the agent fills out. A document is typed JSON that lives in the session log, so it survives crashes and moves with the session. Tools can edit documents through io.docs, and each edit is committed to the log alongside the tool result, ensuring the document's durable state stays consistent with the tool call itself.

Apps can read and edit the same document without needing their own database, and chat routes can even stream each change to the UI. In fact, the virtual() workspace mentioned earlier is built on documents: its file tree is a document in the session log, and each tool call's changes are committed along with its result.

Conclusion

Developers choose a harness based on the choices it makes about prompts, tools, and context. How a harness withstands crashes shouldn't have to be one of those choices. With durable-harness, a turn that loses its function midway continues on a new function from the log—no manual retries and no repeating completed work. By building on the Workflow SDK's World interface, self-hosting and portability come out of the box. durable-harness is open source on GitHub.

For teams using coding agents, this means agents can truly be treated as reliable infrastructure components—even if the underlying function crashes, the session recovers seamlessly, and completed computation is never billed twice.