Fork-per-issue from one warmed repo box

[stubbi]

Summary

Resolve issue clusters faster by warming one box per repo and snapshot-forking a clone per issue, instead of provisioning a fresh workspace per issue.

clownfish resolves clusters of issues in bulk at scale, which means many parallel codex agent runs over the same repository. The expensive, identical-per-run work (clone the repo, install dependencies, warm caches, build) is paid once per issue today.

Proposal

• Warm one box: clone + deps + build once for the target repo.
• Snapshot-fork a clone per issue: each agent gets an isolated, identical workspace in sub-second, already past setup.
• Run agents in parallel across the forks; discard each fork on completion.

This is a textbook consumer of:

• mitos (https://github.com/mitos-run/mitos) directly: pre-warmed pool + fork per issue.
• or the fork-warmed-lease fan-out primitive proposed for crabbox: https://github.com/openclaw/crabbox

Why

Two wins: setup cost drops from O(issues) to O(1) per repo, and each issue's agent runs in an isolated box so a destructive or runaway run cannot poison sibling runs over the same checkout.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 4, 2026, 9:15 PM ET / August 5, 2026, 01:15 UTC.

Summary
Keep open for a maintainer product decision: current main caches tooling and parallelizes selected preflights, but it still creates fresh target checkouts rather than isolated forks of one warmed repository.

Reproducibility: not applicable. this is a design proposal, while current source establishes the fresh-checkout behavior it seeks to replace.

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 ProjectClownfish adopt an opt-in warmed snapshot-fork workspace model, or retain fresh clones with dependency caches?	Measure and design a guarded pilot: Set workload targets and an isolation contract before selecting or building a snapshot backend.

Why: The choice establishes the worker isolation and trust boundary, which the performance proposal alone cannot safely determine.

Next step
A maintainer must choose the workspace backend and isolation contract before implementation can be safely bounded.

Review details

Best possible solution:

Approve a measured, opt-in workspace-pool design only after it defines immutable revision-pinned bases, copy-on-write forks, secret exclusion, cleanup, and fallback to the current fresh-clone path.

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

Not applicable: this is a design proposal, while current source establishes the fresh-checkout behavior it seeks to replace.

Is this the best way to solve the issue?

Unclear: snapshot forking may reduce setup cost, but the backend and isolation contract need maintainer direction before implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A shared warmed base needs an explicit isolation contract for Git state, credentials, caches, copy-on-write mutations, cleanup, and revision pinning before it can replace fresh-clone boundaries.

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

Label changes

Label justifications:

• P3: This is a speculative infrastructure-scaling proposal without an established user-facing regression.
• impact:other: It concerns worker throughput and isolation, meaningful operational impact outside the specific owned impact categories.

Evidence reviewed

What I checked:

• Fresh worker checkout remains the current behavior: The worker workflow deletes the per-repository target directory and performs a shallow clone before execute or autonomous runs. (.github/workflows/cluster-worker.yml:382, 4e295fb8f3ab)
• Preflight explicitly rejects checkout reuse: External merge preflight fails when its target path already exists, then creates a fresh filtered clone; this is the opposite of snapshot-fork reuse. (scripts/preflight-external-pr-merge.mjs:856, 4e295fb8f3ab)
• Isolation guard has regression coverage: The current test requires preflight to reject a preexisting target checkout before running Git commands. (test/preflight-external-pr-merge.test.mjs:590, 4e295fb8f3ab)
• Existing parallelism is narrower than the proposal: Current code supports bounded concurrency for external merge preflights, but it does not supply a shared warmed target-workspace primitive. (scripts/run-external-merge-preflights.mjs:18, 4e295fb8f3ab)
• Related merged workflow work: Merged PR perf(workflows): parallelize external merge preflights #230 added bounded external-preflight concurrency, confirming an adjacent optimization path rather than implementing snapshot-forked workspaces. (0b879d63b58e)

Likely related people:

• vincentkoc: Authored the merged external-preflight concurrency work, the closest evidenced current scaling change in this pipeline. (role: recent adjacent workflow contributor; confidence: medium; commits: 0b879d63b58e; files: scripts/run-external-merge-preflights.mjs)

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.