IronClaw proposes a Pi sandbox worker as its fresh-start default

The underlying architecture spike moves the compiled loop into a persistent per-user container while leaving scheduling, authorization, model access, transcripts and exit validation on the trusted host. The follow-on proposal replaces the fresh-start choice with a pinned Pi worker and adds a checkpoint schema and host-backed calls. This is not merely swapping a command name: the worker can see selected content, but it does not inherit the secret store or the right to authorize effects.

The source is unusually explicit about migration. A saved local-dev configuration remains in-process; a benchmark that deliberately selects another profile or disables the worker still wins over the new default. That preserves an operator’s existing decision instead of using an upgrade to silently redraw the execution boundary. The base architecture record remains an earlier opt-in spike, so its default wording must not be confused with the newer proposal.

The facts

- PR #8075 is stacked on #7908 and proposes hosted-single-tenant-volume-sandboxed as the fresh default boot profile. - Fresh default startup would require Docker and a matching worker image, while explicit profile and worker overrides remain authoritative. - Pi is content-visible only through message references issued for the current run; provider credentials remain on the host. - The author reports a real-container Pi integration pass but says repeated Docker Hub pulls prevented a clean full pinned Dockerfile build. - Related PR #8067 proposes a bounded boot/periodic sweep to recover background deliveries that remain stranded when the parent thread never runs again.

Why it matters

Moving an agent loop across a process boundary only helps if authority stays legible. The host must correlate messages, tool requests, checkpoints, approvals, cancellation and terminal outcomes to the same run. The background-delivery proposal tackles a related custody gap: a result can be durable in a parent transcript yet never become visible if the wake was refused and the parent does not run again. Persistence alone is not notification.

Current

Inspected on 2026-09-06. The IronClaw stable-release baseline is ironclaw-v1.4.0 published 2026-08-28T11:19:24Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is nearai/ironclaw PR #8075 (https://github.com/nearai/ironclaw/pull/8075). Supporting context comes from nearai/ironclaw PR #7908 (earlier design context) (https://github.com/nearai/ironclaw/pull/7908); nearai/ironclaw PR #8067 (https://github.com/nearai/ironclaw/pull/8067). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

Evaluate runtime conformance and reproducible packaging independently. The contributor’s container smoke checks the Pi process, mediated shell output and final reply, but does not prove a clean build of the pinned image or model-quality gains. For background recovery, test an idle parent and multiple competing backlogs; the proposed sweep uses keyset paging, a delivery cap and round-robin parent groups. Keep autonomous-wake streak limits intact so recovery does not turn a deliberate deferral into unauthorized new work.

Caveat

The default-switch and recovery proposals were open at inspection. The author reports no loop-quality benchmark or live-provider canary, and an automated review was blocked by expired authentication. None of those blocked checks is counted as passed here.