The shared-runtime model

A shared runtime means one operating system and one set of already-started applications serve many attempts at once. Each attempt sees its own files, its own clipboard, its own screen and its own input. The code, the kernel and the warmed caches are shared. This note describes the model and, more importantly, the list of things that break it.

The parts

Copy-on-write, in plain words

Copy-on-write means two copies of something share the same bytes until one of them writes. Only the changed part is duplicated. It exists at several layers, and they are not interchangeable:

• Files: APFS clonefile on macOS, cp --reflink on XFS and Btrfs, overlay filesystems, qcow2 overlay disks.
• Databases: a Postgres template database, a MySQL data directory cloned by reflink (CUA-Sandbox uses both).
• Live memory: a forked process, or a VM memory snapshot mapped write-protected (VenusRL and similar microVM fleets).

Reset, replay, restore, branch

• Reset. Kill the attempt's applications, clear the clipboard, swap in a pre-cloned work tree, verify it against a manifest, relaunch, check readiness, then publish generation g+1. On macOS this is a rename-swap of an APFS clone; on Linux the same with reflink or an overlay. Not reset: anything outside the manifest.
• Restore. Bring back a saved state. Files only (macOS, Prime-style sandboxes), or files plus processes (Linux with CRIU). Restore fidelity is a correctness gate before any performance comparison: see checkpoint and restore.
• Branch. Two or more continuations from one intermediate state, for example after an agent has opened a document and reached step k. This is the differentiating experiment; see the rollout loop.
• Replay. Re-apply a recorded action list after a reset and compare the final state hash. Used to check that reset and restore are faithful.

The generation counter

Every attempt has an integer generation. Every mutating call (click, type, launch, clipboard write, reset) carries the generation it was issued for. The check and the effect are one atomic step, so a reset cannot land between them. A call with an old generation is refused with an error (HTTP 409 in our implementation), does nothing, and the action log must show it was never applied. CUA-Sandbox published the same protocol with a measured check: 0 of 100 mixed-generation events with the protocol on, 100 of 100 with it off (author-reported). Our isolation test 10 repeats that check with 100 resets fired mid-step.

What must be scoped

This is the list that decides whether sharing is correct for training. Each item is a place where one attempt's state can reach another's. If any one of them is shared, a reward can be wrong and the training data is poisoned without anyone noticing.

Not a security boundary

Scoping the list above is enough for training correctness if, and only if, the checks confirm it. It is not a security boundary. On macOS every session shares one kernel, one WindowServer and one root; a process in one session is one user account away from another, not one machine away. On Linux every namespace shares the host kernel. An agent that runs arbitrary code can cross any of these on purpose. Published VM-based systems name kernel isolation as a security requirement for exactly that reason (EvoCUA, author-stated). Drums measures accidental cross-talk over stated environment-hours; it does not defend against a hostile agent.

The variants we are building or comparing