What happened
On October 26, 2026, Cloudflare announced new durability and approval features for @cloudflare/computer. Cloudflare describes Computer as a workspace in which an agent can run code. Starting with version 0.7.0, code using its Worker JavaScript backend can resume after a deployment or crash, and can pause while an external application makes a decision such as whether to approve a tool call.
Recovery is configured with onInterrupt: "replay" on WorkerJavaScriptBackend, or for an individual run. The documented example places a Workspace in a Durable Object, using the Durable Object storage and a Worker JavaScript backend. When recovery occurs, the JavaScript runs again from the beginning. Completed calls whose results were recorded are reused, and output that was already recorded is not printed again.
That is replay, not a blanket guarantee that an interrupted operation will never happen twice. Cloudflare explicitly warns that if a call result was not recorded before the interruption, recovery may repeat the call even when the action has already succeeded. Its guidance points builders toward retry handling and unsafeToRepeat() for operations that cannot safely be repeated. Recovery begins on the next call to workspace.runtime; a Durable Object alarm can call workspace.runtime.recover() when recovery should not wait for incoming traffic.
The same release provides an approval-pause mechanism for functions exposed through custom modules. A module function can call ctx.interrupt() with data for the application to inspect. In Cloudflare’s GitHub example, an agent imports postComment from a custom ws:github module and calls it normally. The module pauses at ctx.interrupt() until an application supplies an approval decision. If approved, it posts the comment with ctx.callId as the idempotency key; if not, it throws an error.
Applications can retrieve pending calls with workspace.runtime.pending() and resolve them with respond(). A run continues after all pending calls are resolved. Cloudflare says time spent waiting for a decision does not count against the run timeout, and that the waiting state survives deployments. The announcement directs readers to its separate documentation for setup, current limitations, and replay behavior.
What the archive adds
We have not covered this before; it opens a new thread. The archive does contain earlier Telegram coverage of resumable, approval-gated execution in Vercel Run and of Cloudflare’s interest in long-running agent infrastructure. This release is a new concrete implementation detail: replay recovery and pending approval resolution in Cloudflare Computer.
Trend signal
This supports Agent security moves to runtime boundaries. The meaningful control is not an instruction telling an agent to be careful before posting a comment; it is a runtime pause that hands a bounded decision to the application. It also supports Harness architecture outlives model choice: replay policy, stored call results, alarms, pending calls, and idempotency are properties of the execution harness, independent of which model produced the code.
Connections to other events
An earlier Telegram post described Vercel Run as resumable sandbox execution with approval gates. Cloudflare Computer reaches a similar operational shape through a Worker JavaScript backend and Durable Objects: work can stop, retain a pending decision, and continue later. The distinction in this announcement is its explicit replay model and warning that unrecorded calls may be retried.
Why it matters
Agent teams often treat a tool call as a short, synchronous event. That assumption fails once a task spans deployments, process interruption, API latency, and a human approval queue. Cloudflare’s release makes the boundary visible: the system can replay code, preserve completed call results, hold a pause without consuming timeout, and resume after an application resolves it.
The operational consequence is that a team must classify every external effect. Posting a comment, charging a card, changing a record, or triggering a deployment cannot be made safe merely by placing an approval screen in front of it. Builders need idempotency keys where possible, a deliberate policy for calls that must not be repeated, and tests that simulate interruption at inconvenient points. Approval gates improve control, but they also create a state machine that must be owned.
What happens next
- More Computer examples will focus on idempotent external actions and recovery testing. (3 months, 65%). Watch for: additional documented module patterns beyond the GitHub comment example.
- Teams adopting replay recovery will formalize which tool calls may be retried. (6 months, 70%). Watch for: explicit unsafe-operation registries, idempotency conventions, or approval policies in agent deployments.
Limits and uncertainty
The announcement establishes feature behavior, not production reliability or adoption. It does not provide performance figures, limits on pending calls, pricing, supported deployment configurations, or evidence that replay reduces failures in a production workload. It also does not specify every kind of external call for which unsafeToRepeat() is appropriate, nor does it make an approval decision itself safe from application-level mistakes. The source says recovery can repeat an unrecorded call; it does not quantify how frequently that condition occurs. Teams should consult the linked setup and limitations documentation before treating the changelog example as a complete design.
Skill to build now
Create a small interruption test for one agent tool this week. Make the tool write an idempotency key tied to the execution’s call identity, then simulate an interruption after the external service may have received the request but before the result is stored. Decide whether replay is allowed, whether the operation must be marked unsafe to repeat, and what an approver sees before resolution. Test both approval and rejection paths, plus a restart while the request is pending. The useful output is a written retry contract for that tool, not merely a successful demo.
Reader takeaway
Cloudflare Computer v0.7.0 turns two difficult agent behaviors into runtime primitives: recoverable execution and durable approval pauses. That is useful only if a team designs for the uncomfortable edge case Cloudflare highlights: a replay can repeat an external effect whose result was never recorded.
Open question
How will Cloudflare expose and constrain the lifecycle of many concurrent pending approvals, especially when the associated external actions have different replay and idempotency requirements?