Cua Durable Spaces adds crash recovery with the --durable flag

• Cua adds crash recovery to existing coding agents with --durable, supporting Claude Code, Codex, Hermes and OpenCode in its launch instructions.
• A killed agent resumes with recovery context: Cua says its first message identifies completed tool calls and calls that may have run halfway.
• A lost machine triggers a fresh start elsewhere, as Cua's failover announcement explains. Task files need separately shared storage in Cua Volume.

Cua's unusually candid crash-test results include tool effects that ran twice under Hermes. Imported Claude Code sign-in passes only an access token, never the refresh token.

Durable Spaces pools computers connected to a Cua account. The launch command wraps an existing harness:

The runner connects through the Agent Client Protocol (ACP), according to Cua's implementation guide. --on auto chooses the machine running the driver; an optional --in binds the session to a durable Space.

Cua distinguishes several failure paths in its recovery measurements:

• Agent process dies: the driver restarts it in place, up to three times, and reloads its session.
• Driver process dies: a new driver starts a new Space on the same machine. The journal survives, but the harness's original session files disappear with the old Space, so a recovery summary substitutes for the conversation. Cua measured 40 to 80 seconds with Claude Code and Codex.
• Driver's Space is killed or runs out of memory: the machine detects the stopped Space and ends the driver. Cua measured about 55 seconds from a Space kill to Claude Code resuming.

The recovery note names the interrupted request, completed calls and potentially partial calls. A turn that already ended is never replayed.

Each replacement driver raises an epoch fence before writing. An older driver sees that higher epoch on its next write, stops and exits with code 75.

Cua's tool-call guarantees depend on whether the harness asks permission. The driver writes and syncs an intent record before answering each permission request.

• Permission-requesting calls: each call ID is approved once. If its outcome is unknown after a crash, a repeated request is refused and recorded as may_have_run.
• Read-only exceptions: the rerun-safe policy permits another approval for calls the harness classifies as read, search or fetch.
• Unguarded calls: tools that never request permission can run again after recovery. Partial side effects, including partly written files or surviving processes, are not rolled back.

Default guard mode keeps approval requests flowing and answers with “allow once.” Those approvals are automatic; the Space remains the security boundary.

At-most-once applies to a call ID. The model can still issue the same action again under a new ID.

Cua's per-harness campaign used real harness binaries against a scripted offline model on Linux with Docker. The measured versions exposed substantially different permission coverage:

• Claude Code 2.1.281: every state-changing tool requested permission. Two of 160 effects still ran twice because the scripted model issued new call IDs without reading the recovery note.
• Codex 0.156.1: guard mode selects “Ask for approval,” but only commands requesting escape from Codex's sandbox are guarded. Commands staying inside its sandbox have outcome records only.
• Hermes 2026.9.21: only dangerous commands requested permission. Ten of 160 effects ran twice after a kill; Hermes reports calls only after completion, leaving interrupted calls absent from the ledger.
• OpenCode 1.18.32: guard mode requests permission for bash, edit and webfetch. Without guard mode, 11 of 160 effects were lost and flagged in the recovery note; no duplicates appeared in that run.

The campaign produced no repeated approval request in 200 runs. The driver's refusal of an already-approved call ID was exercised by its own tests.

The default journal lives in the run's data folder on the driver machine. A replacement on another host has neither that journal nor the old working folder.

Cua measured roughly 65 to 75 seconds before recording an unresponsive host as lost and starting the next drive elsewhere. Its failover guide specifies five total drives by default, counting the initial run and every restart, configurable with --max-attempts.

Cua Volume preserves files beyond a Space's lifetime, with an important storage distinction:

• “This Mac,” the default: files live in a folder on one computer. Another machine cannot see them.
• S3-compatible storage: a user-supplied bucket, such as AWS S3, R2 or MinIO, makes the files reachable from each machine.

A durable Space recreated after losing its host has an empty disk. The ACP journal records conversation and tool activity, not a workspace image.

Durable runs appear in cua agent sessions and use session:NAME identifiers for management:

Cua's current recovery documentation describes several monitoring limits:

• Silent driver: after 120 seconds without output, the coordinator cancels and replaces it. --stall-secs changes that threshold; zero disables it.
• Startup grace: a driver that has emitted nothing receives at least 600 seconds for installation.
• Incomplete logs: cua agent logs session:NAME currently shows driver heartbeat lines rather than the agent's activity.
• Live but stuck agent: the driver emits a heartbeat every stall_secs / 4, or 30 seconds at defaults. A model call can hang indefinitely while that timer continues, so the stall detector does not catch it.