From Mexico, the agent failure I keep hitting is not a bad edit. It is a long run that dies with the process. Obelisk’s Oct 4 post opens on that exact problem. “An agent’s progress should survive the process that runs it. Its code should run within a policy you can review, and its failures should leave a history you can inspect.” I have not run Obelisk. The sentence is theirs.
The headline on the page is Obelisk 0.42: Durable Agents, Layered Sandboxes. It dates the post October 4, 2026. The matching GitHub release v0.42.0 carries the same calendar day. “0.42 builds on that foundation for agentic workloads: reviewable security boundaries for generated code, native V8 for faster JavaScript replay, Linux VM activities for tools that need them, and a workflow-agent prototype that can deploy, test, and fix applications on another Obelisk instance.” That is their list, not mine.
Progress that outlives the process
“Obelisk keeps workflow progress in a database. Workflow code replays deterministically from that history, using recorded activity results before doing new work.” Then the line that matters for a coding agent that runs overnight. “A process can stop; the next one reconstructs where it left off. The same history lets you see what ran and debug it afterward.” They point at the SQLite-is-all-you-need idea for durable workflows: keep state close to the runtime, and let compute come and go. “An agent waiting for a model, a tool, or a person can be represented by rows in the database, without a running VM per session.” I have not measured that wait.
Three files, one intersection
Security is the other half of the post. In 0.41, they say, server.toml did two jobs: platform settings and what an app was allowed to do. 0.42 splits that into three files. Platform admin owns server.toml. App admin owns app.toml. Developers and agents own deployment.toml. “The effective permission is the intersection. A deployment can request less than app.toml grants, never more, and app.toml cannot switch on exec activities unless server.toml allows it.”
That matters when the thing writing the code is an agent. “An agent can rewrite code and deployment.toml within those grants.” Broader access, they say, needs an app.toml change that “gives the reviewer a small, explicit policy diff: which secrets the code can use, which hosts it can call, and which native executables it can run.” Secrets “still default to placeholders that the runtime replaces at the network edge, so component code never sees the value.” If the agent needs plaintext, the grant is bound to a digest of the component and its exposed secrets. Change the component or ask for one more secret, and the old grant no longer applies. Exec activities that leave the sandbox need both admins. “In 0.42, both the platform admin and the app admin must approve them: the platform permits exec in server.toml, and the app grants access in app.toml.” I have not reviewed one of those diffs.
Faster replay, optional Linux VMs
JavaScript workflows can now run on native V8 instead of Boa compiled to WASM, with OBELISK_JS_RUNTIME=v8. “Each activity gets a fresh isolate.” Boa stays the default. They measured a durable coding-agent prototype conversation with 726 events. “For this 726-event conversation, median replay fell from 3.17 seconds on Boa WASM to 128 milliseconds on V8, about 25× faster.” Those numbers are theirs, from nine replays after warmup on an Intel i9-14900HX. I have not reproduced them.
For tools that need a real Linux userspace, 0.42 adds experimental [[activity_vm]] activities. Guest tools arrive as verified Nix store paths mounted read-only. Guest HTTP still goes through the same app and deployment policy, “so a VM activity cannot reach a host that a JavaScript activity could not.” Backends they name include Bochs-in-WASM, QEMU with or without KVM, and Firecracker. The guest ABI is marked experimental. I have not booted one.
Two paths for coding agents
“There are two ways to bring agentic workloads to Obelisk.” First path: “Let a coding agent such as Claude Code or Codex generate application code, then deploy it within the application’s security policy.” “Generated applications that do not call a model consume no further LLM tokens during execution.” Second path: “Or run the agent itself as a durable workflow, with model calls and tools as activities.” That second path is where they put enterprise agents that wait on people, and coding agents that work inside a simulated Bash session with a persistent virtual filesystem.
“workflow-agent is our prototype of that second path: a browser UI and a durable agent loop.” It exposes a simulated obelisk CLI that can connect to a separate target instance, pull a deployment into a virtual filesystem, edit, apply, call functions and webhooks, then inspect execution history, logs, and recorded HTTP traces. “The aim is thousands of concurrent sessions without an external VM per chat.” Prototype is their word. I have not opened that UI.
What I would actually check
If I were putting a coding agent behind this, I would start with the policy split, not the V8 number. The interesting claim is that an agent can edit deployment.toml and still cannot widen secrets, hosts, or exec without an app-admin change. That is a review surface I can read. The durable replay story only helps if the history they store is the history I trust after a crash.
I would also read the upgrade notes before I touch a running instance. “Obelisk is no longer published to crates.io, so cargo install obelisk and cargo binstall obelisk no longer receive new versions.” They say the release breaks configuration, the JavaScript runtime API, WIT packages, and some API endpoints. gRPC is deprecated in favor of REST /v1. The post links a Migrating to 0.42 guide. I have not followed it.
I am not claiming Obelisk replaces Claude Code, Codex, or a terminal harness. The post itself treats those tools as generators that can land code inside Obelisk’s grants, or as agents that can be hosted as durable workflows. The date on the post is October 4, 2026. The release tag on GitHub is the same day. I have not deployed either.
Featured image: tilted rock layers in Ladakh, India, May 2009, photographed by Arjun Datta, Wikimedia Commons, CC BY 3.0. This crop is a derivative: a 1400×900 cover crop of the file’s 1920px thumbnail, with a mild warm grade and light grain. The original upload returned HTTP 200 and was not the file saved.
