Shared-OS spike in an authoring sandbox, namespaced Xvfb tree launched and swept, CRIU absent

In one paragraph

This is the only measured artifact on the whole claude/ecstatic-archimedes-456go6 branch. A small diagnostic (sharedos_spike) launches one process tree in private pid, mount, net, ipc and uts namespaces, running an Xvfb display, an xterm and a tiny stateful probe app, then runs a list of gates: prerequisites, launch, live-state probe, CRIU dump, restore of live process state, restore of X state, isolation between two restored copies, reset, GUI pixel review and cleanup. It ran once, in the authoring sandbox, where CRIU is not installed. Launch, live-state probe and cleanup passed (measured). Prerequisites failed because criu was missing. Every checkpoint-related gate was NOT_RUN, the GUI gate is REVIEW_REQUIRED, and the report's own overall verdict is all_gates_pass: false. It shows that the tree can be started and torn down cleanly. It shows nothing about checkpointing, and it is not the Drums runtime and not OSWorld.

Setup

The spike is a reduced-scope, public-mechanism diagnostic. The report labels itself: "SHARED-OS RUNTIME SPIKE - reduced-scope Xvfb diagnostic; not OSWorld, not Drums, not a cost or training claim".

• Host: the development/authoring sandbox. The report records "evidence": "sandbox_diagnostic" and ends with the note "Committed copy: artifact paths rewritten relative to this file; everything else is the raw run output. Sandbox run, CRIU absent." It does not record a hostname, kernel version or timestamp, so the environment is "authoring sandbox, unidentified".
• Tree: unshare --pid --fork --mount-proc --mount --net --ipc --uts --propagation private running python3 -m sharedos_spike.tree --marker spike-b114cf4c2f15 --display :170. Inside it: Xvfb :170 -screen 0 640x480x24 -nolisten tcp -noreset, an xterm titled sharedos-spike that prints the marker, and sharedos_spike.stateapp serve holding a 32-hex token and a counter in memory only.
• Probes run through nsenter --target 461 --mount --pid from the host: the state app (two queries), a framebuffer grab as PNG, the process table, and the X server's own window list.
• Gate rules written into the tool: a gate whose prerequisite failed is NOT_RUN, never PASS; the GUI gate stays REVIEW_REQUIRED until a human records a decision with review.py citing the sha256 of every PNG; cleanup is itself a gate and must prove that no marker-identified process remains.
• Declared fidelity differences carried in the report: not the OSWorld Ubuntu image; shares the host kernel; Xvfb software framebuffer; pid/mount/net/ipc/uts namespaces only, no user namespace and no cgroup CPU or memory limits; only /tmp is private; CRIU restore needs privileges and the same kernel and CRIU build; the GUI-state gate is a framebuffer hash.

What ran

One invocation of python -m sharedos_spike diagnose in the sandbox, committed first at d1bf58f (2026-10-25 05:31 UTC) and re-added in its committed form at 43ecfd2 (05:43 UTC). The run launched the tree (host pid 461 for the namespace init), queried the probe app twice, grabbed the framebuffer twice, read the process table and the X window list, then swept every process carrying the marker.

Results

The gate verdicts, quoted exactly from report.json:

• prerequisites: FAIL, "criu absent: dump/restore gates cannot run (launch/probe gates still run)", missing_tools: ["criu"].
• launch: PASS, "tree up".
• live_state_probe: PASS, "baseline state readable (GUI still needs human PNG review)". All eight checks are true: token_is_32_hex, counter_advances, raw_png_captured, framebuffer_stable_when_idle, xvfb_process_for_display, xterm_process_with_title_and_marker, probe_app_process, x_server_lists_one_mapped_window_with_that_title.
• dump, restore_live_process, restore_x_state, isolation, reset: NOT_RUN, "criu absent".
• gui_pixel_review: REVIEW_REQUIRED, "a human must look at these raw PNGs and record a decision (review.py); hashes and semantic checks do not replace that".
• cleanup: PASS, "no marker-identified process remains". Terminated pid 461; force_killed: [], failures: [], remaining: [].
• all_gates_pass: false.

Measured details behind the PASS gates: the probe app returned the same token on both queries with the counter at 7 and then 16, so the app was alive and advancing between queries. The process table inside the namespace listed pid 1 (the tree init), pid 3 Xvfb, pid 6 xterm, pid 7 the probe app, pid 9 a sleep and pid 14 the process-table probe itself. The X server listed exactly one mapped top-level window, id 2097164, title sharedos-spike, viewable.

What the PNG shows

Both PNGs are byte-identical (same png_sha256, distinct_colors: 2, 640x480). We opened one: a black Xvfb root with a single white xterm window in the top-left corner reading SHAREDOS-SPIKE spike-b114cf4c2f15 and a cursor block. That matches the branch README's description. By the tool's own rule, a pixel hash is not evidence of application state (a black screen with a cursor would pass it), which is why the GUI gate stays REVIEW_REQUIRED. No review file exists on the branch, so the GUI gate is still open.

What it does not show

No CRIU checkpoint or restore was taken. The branch README says it plainly for this spike: "No CRIU checkpoint or restore has ever been executed by this work." Nothing here says whether an in-memory token survives a restore, whether the framebuffer comes back, whether two restored copies are isolated from each other, or whether a reset by re-restore works. Those are the questions the spike was built to answer, and none of them was reached. There is also no resource limit on the tree, so nothing about cost or matched resources is measured.

Failures and surprises

The prerequisites gate failed on the missing criu binary, which was expected in the authoring sandbox. The surprise is in the branch's own history: later documents on the same branch describe operator CRIU dumps and restores on other code (see EXP-008, EXP-009 and EXP-010), none with an artifact, while this spike, the only measured run, never touched CRIU.

Limitations

• Unidentified sandbox: no hostname, kernel or timestamp in the report.
• CRIU absent, so five of ten gates did not run.
• Not OSWorld and not the Drums runtime: no guest kernel, systemd, GNOME session, Nautilus or OSWorld guest server.
• No cgroup limits, no user namespace, only /tmp private: "equal guest resources with the VM baseline" is not satisfied.
• Command latencies in the report (0.004 s to 0.16 s, measured) are nsenter wrapper timings and say nothing about workload performance; they are left out of the result table on purpose.
• The GUI gate needs a human review that nobody has recorded.

Reproduce

From the branch checkout, in benchmark/, on a Linux host with root, unshare, nsenter, Xvfb, xterm and CRIU installed:

python -m sharedos_spike diagnose --plan                         # prints the commands, executes nothing
python -m sharedos_spike diagnose --work NEW_DIR --out report.json
python -m sharedos_spike.review report.json REVIEW OUT            # human PNG decision, must cite every PNG sha256

Exit code 0 means every gate passed including the review; 3 means only the human review is outstanding; 1 anything else. Running it where CRIU is present is the next real step; the branch expects "a FAIL on a real host is plausible and would be informative" because of unix sockets and X connections.

Sources

• benchmark/sharedos_spike/reports/sandbox-run/report.json (measured; the only run artifact on the branch)
• benchmark/sharedos_spike/reports/sandbox-run/artifacts/00-before-dump.png and 01-before-dump-again.png (measured, byte-identical)
• benchmark/README.md, section "Shared-OS runtime spike (reduced-scope diagnostic; not OSWorld, not Drums)"
• benchmark/sharedos_spike/__init__.py (fidelity differences and public sources), benchmark/sharedos_spike/review.py
• Commits d1bf58f and 43ecfd2 (2026-10-25)