Add a mitos snapshot-fork sandbox provider + fork-warmed-lease fan-out

[stubbi]

Summary

Add a mitos backed sandbox provider to crabbox, and a primitive to fork one warmed lease into N clones.

mitos (https://github.com/mitos-run/mitos) is a snapshot-fork microVM engine: it boots Firecracker VMs, keeps pre-warmed pools, and forks them via copy on write snapshots in sub-second, with real microVM isolation. crabbox already abstracts providers (aws, azure, gcp, hetzner, ssh, e2b, modal, daytona, runpod, ...) behind SSH and delegated backends, so this fits the existing seam.

Why

Two gaps this addresses:

1. Warm box latency. crabbox warms a box and rsyncs the dirty checkout per lease. A mitos provider can hand back a snapshot-restored microVM from a pre-warmed pool, so the box is warm from the first lease instead of provisioned per run.

2. Isolation for agent use. crabbox's own trust model states it is a developer execution tool, not a security sandbox, and assumes a cooperative trusted team. When the caller is an AI agent running unreviewed code, microVM isolation is the missing boundary. A mitos provider gives crabbox an isolated execution mode without changing its control plane.

Proposal

• New provider adapter (internal/cli), most likely a delegated-run backend: crabbox calls Warmup / Run against a mitos pool, mitos owns provisioning and isolation.
• Auth and pool config via the usual provider Spec() declaration.

Bonus: fork-warmed-lease fan-out

mitos's native trick is forking a running VM. Expose a crabbox primitive to fork one warmed lease into N identical clones, then run the same suite across them:

• matrix builds from one warmed state
• flaky-test retry without re-warming
• bisect across many commits in parallel

Each clone inherits the warmed box's memory and filesystem, so fan-out cost is the fork, not a fresh provision per shard.

References

• mitos: https://github.com/mitos-run/mitos
• Companion consumer issue (fork per issue): to be filed on https://github.com/openclaw/clownfish

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 31, 2026, 2:31 AM ET / 06:31 UTC.

Summary
Keep open: the merged provider-neutral checkpoint fan-out work addresses part of the request, but the requested Mitos provider, its microVM lifecycle, and its security contract remain a separate unapproved capability. The July 17, 2026 discussion explicitly welcomes an operator-backed adapter but makes ongoing ownership and live proof prerequisites. Likely related people: steipete for the provider-direction decision; vincentkoc for the existing fan-out implementation.

Reproducibility: not applicable. this is a proposal for a new provider and lease-cloning capability, not a report of broken existing behavior.

Root-cause cluster
Relationship: canonical
Canonical: #529
Summary: This issue remains the canonical tracker for the unimplemented Mitos provider; merged checkpoint fan-out work covers only a provider-neutral subset.

Members:

• partial_overlap: feat(checkpoint): run commands across fork fanout #836 - It implemented checkpoint fork fan-out but expressly excluded a Mitos provider and live-memory fork semantics.
• partial_overlap: feat(providers): recommend fanout testing #605 - It added provider recommendations for fanout testing without implementing Mitos-specific lifecycle support.
• adjacent_distinct: Add a run-a-harness-in-the-box mode (agent runtime) #530 - It proposes an agent-runtime mode that could consume forked leases but has a distinct runtime and HTTP-bridge scope.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should Crabbox accept and support a Mitos provider as an ongoing, security-sensitive provider integration, and who will operate its live proof and maintenance commitment?	Sponsor an operator-backed adapter: Accept a focused provider proposal once a committed operator owns live lifecycle proof, maintenance, and a security review of the Mitos boundary.

Why: The remaining work is not a mechanical extension of checkpoint fan-out: it creates a new provider and an isolation-facing contract whose support burden and security guarantees require explicit maintainer sponsorship.

Next step
A maintainer must first choose whether to sponsor this security-sensitive provider contract and identify an operator who will maintain live proof; it is not safe for an autonomous repair lane.

Security
Needs attention: The issue proposes a new isolation-facing provider boundary, so security review is required before the design can be accepted.

Review details

Best possible solution:

Sponsor a narrowly scoped Mitos provider only with a committed long-term operator, a provider-adapter design that keeps core neutral, and redacted live create/use/fork/destroy proof that validates isolation and teardown; retain the existing provider-neutral checkpoint fan-out as the common execution interface.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a proposal for a new provider and lease-cloning capability, not a report of broken existing behavior.

Is this the best way to solve the issue?

Unclear: provider-neutral fork fan-out is already available, but a Mitos adapter is only the best next step if a maintainer sponsors its lifecycle, security contract, and ongoing live validation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A provider that presents microVM isolation as a security boundary needs a reviewed contract for credentials, network exposure, host access, snapshot inheritance, cleanup, and failure handling before users can rely on it.
• Forking a warmed lease may preserve filesystem and memory state across clones; the adapter contract must define clone identity, secret handling, cleanup, and what provider-level isolation is actually guaranteed.

Codex review notes: model internal, reasoning high; reviewed against e31157d65ba5.

Label changes

Label justifications:

• P3: This is an optional provider and execution-mode proposal with no demonstrated regression in existing workflows.
• impact:security: The central value proposition is a new microVM isolation boundary for unreviewed code, making security semantics a primary review concern.

Evidence reviewed

Security concerns:

• [medium] Define snapshot and clone isolation guarantees
  The proposed microVM and warmed-clone workflow must specify credential propagation, egress, snapshot inheritance, lease identity, and teardown behavior before Crabbox can make an isolation claim.
  Confidence: 0.91

What I checked:

• Maintainer direction: The July 17, 2026 discussion says a Mitos adapter is welcome only when a user will operate it regularly, keep it working, and provide real create/use/destroy proof with clean teardown; that is an explicit ongoing-ownership and validation requirement.
• Merged partial implementation: Merged pull request feat(checkpoint): run commands across fork fanout #836 added provider-neutral checkpoint fork fan-out and explicitly states that it does not add a Mitos provider or claim live-memory fork semantics. (5a8851538789)
• Existing provider recommendation coverage: Merged pull request feat(providers): recommend fanout testing #605 documents fanout-testing provider recommendations without adding Mitos-specific support, so it is related but not a replacement for the requested adapter. (32fc38a116a2)
• Repository boundary: The reviewed repository policy requires core to remain provider-neutral and provider-specific lifecycle, reconciliation, and security semantics to live behind provider adapters; the requested work must therefore establish a complete adapter contract rather than add core-specific Mitos branching. (AGENTS.md, e31157d65ba5)

Likely related people:

• steipete: Their July 17, 2026 comment defines the acceptance bar: a committed operator, an adapter within existing boundaries, and live lifecycle proof. (role: provider-direction decision owner; confidence: high)
• vincentkoc: They authored the merged provider-neutral fan-out work that covers the checkpoint portion while deliberately excluding Mitos lifecycle support. (role: introduced related fan-out behavior; confidence: high; commits: 5a8851538789, 32fc38a116a2)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[stubbi]

Related: #530 (run-a-harness-in-the-box mode). The fork-warmed-lease fan-out proposed here is what makes that agent-runtime mode useful: warm one box with the harness loaded, fork N clones, run N approaches in parallel. Gating dependency on the mitos side: mitos-run/mitos#230

[steipete]

Thanks for the suggestion! Marking this help wanted.

Honest status: Crabbox already supports a good range of providers, and the maintainer is at capacity for adding ones they don't personally use — each provider is an ongoing maintenance and live-proof commitment, not a one-time PR.

That said, this is a genuine invitation: if you (or anyone) have a strong need for this provider and are willing to not just open a PR but also use it regularly and help keep it working, we'd be happy to integrate it. A provider adapter that fits the existing boundaries (core stays provider-neutral; provider-specific lifecycle lives behind the adapter) plus real create/use/destroy proof with clean teardown is very welcome. Comment here if you want to take it on and we'll help.