Obelisk 0.42 Gives Agent-Written Code a Three-Layer Permission Model and Linux VMs

Obelisk, an open-source durable workflow engine published under AGPL-3.0, shipped version 0.42 on October 4, 2026. The release reorganizes the project around one question: how much should code written by an AI agent be allowed to do? It splits the engine’s security policy into three files with three owners, adds native V8 and experimental Linux VM activities, and ships a prototype coding agent that runs as a durable workflow. The project says 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.”

Permissions an agent cannot grant itself

Obelisk stores workflow progress in a database and replays code deterministically from that history. In 0.41, the operator’s policy lived in server.toml next to platform settings. Version 0.42 splits it three ways. The platform admin owns server.toml, which covers resource limits, runtime configuration, and the gate for host execution. An app admin owns app.toml, which grants secrets, outbound hosts, and approved executables. Developers and agents own deployment.toml, where code requests capabilities within those grants.

The effective permission is the intersection of the three files. A deployment can ask for less than app.toml allows, never more, and app.toml cannot turn on exec activities unless server.toml permits them. In practice, an agent can rewrite its code and its deployment file freely. Any request for broader access becomes a small, explicit diff in app.toml for a human to review, listing which secrets, which hosts, and which native executables. obelisk deployment verify reports missing policy entries, and --fix scaffolds them for review. Every deployment also records a digest of the app policy it was activated under.

Secrets get the same treatment. By default, component code sees placeholders that the runtime swaps for real values at the network edge. When code genuinely needs plaintext, such as a webhook checking an HMAC signature, it asks through exposed_secrets. The matching grant is bound to a digest of the component and its full set of exposed secrets. If an agent edits the component or asks for one more secret, the digest changes and an admin has to approve it again. Exec activities, which run host processes outside the sandbox, now need sign-off from both the platform admin and the app admin.

Faster replay and real Linux when tools need it

JavaScript workflows, activities, and webhooks can now run on native V8 instead of the Boa interpreter compiled to WebAssembly, by setting OBELISK_JS_RUNTIME=v8. Boa remains the default. Replay speed matters because a durable session has to rebuild its state before it can resume. Replaying a 726-event agent conversation, the project measured a median of 3.17 seconds on Boa WASM and 128 ms on V8, about 25 times faster. The same workflow written in Rust and run under Wasmtime replayed in a median of 106 ms.

The experimental [[activity_vm]] runs a script inside a Linux VM, with tools supplied as verified, read-only Nix store paths. Guest HTTP goes through the same app and deployment policy as every other component. Backends range from a Bochs emulator compiled to WASM to QEMU, with or without KVM, and Firecracker microVMs. On the project’s test host, a Bash print finished in a median of 0.155 seconds on Firecracker and 0.144 seconds on QEMU with KVM, against 0.966 seconds on Bochs WASM.

Two ways to run agents

The release describes two paths for agentic work. In the first, a coding agent such as Claude Code or Codex writes an application that Obelisk deploys within its policy, so the running app spends no model tokens unless it calls a model itself. The project credits this idea to Kelsey Hightower’s Zero Token Architecture talk at PlatformCon 2026. In the second, the agent itself runs as a durable workflow, with model calls and tools as activities, inheriting parent-child hierarchies, scheduling, and pause-and-resume from the runtime.

The workflow-agent prototype takes the second path. It pairs a browser UI with a durable agent loop and gives coding agents virtual Bash workspaces with a persistent filesystem. Through a simulated obelisk CLI, it can pull a separate Obelisk instance’s deployment, edit the code, redeploy, call functions and webhooks, and read execution history, logs, and recorded HTTP traces to fix what broke. The goal is thousands of concurrent sessions without a VM per chat.

Breaking changes

Version 0.42 breaks configuration, the JavaScript runtime API, WIT packages, and some API endpoints; a migration guide covers each step. Obelisk is no longer published to crates.io, and gRPC is deprecated in favor of the REST /v1 API. Unlike crash-recovery libraries built into a single agent harness, Obelisk puts durability and the permission boundary in the runtime underneath the agent.