Repository navigation
Fork-per-issue from one warmed repo box #168
Description
Activity
Codex review: this still needs some work.
Summary
Current main does not implement warmed workspace forks, so this issue cannot close under the repository’s implementation-only cleanup policy.Reproducibility: This requests a new capability; source establishes separate checkout provisioning, but no benchmark verifies the claimed cost or sub-second fork performance.
Maintainer decision needed
- Question: Should Clownfish sponsor a bounded evaluation of warmed workspace forks?
- Recommendation: Measure before adopting: Compare cached provisioning with one warmed-fork provider, including setup cost, revision freshness, isolation, and credential separation.
- Why: The capability remains absent, but source and discussion establish neither measured savings nor an adoption decision for mitos or crabbox.
Next step
Decide whether to sponsor a measured provisioning comparison before committing to warmed workspace infrastructure.Review details
Best possible solution:
If sponsored, evaluate revision-pinned disposable forks against current cached provisioning before adopting a provider.
Do we have a high-confidence way to reproduce the issue?
This requests a new capability; source establishes separate checkout provisioning, but no benchmark verifies the claimed cost or sub-second fork performance.
Is this the best way to solve the issue?
Warmed forks are plausible, but a measured comparison should establish value and preserve existing integrity and credential boundaries before provider integration.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
- The report provides no measurements of setup cost or fork latency against current cached provisioning.
- Provider selection, snapshot freshness, credential separation, and compatibility with fresh-checkout integrity checks remain unspecified.
Codex review notes: model internal, reasoning medium; reviewed against d2fb381d6f39.
Label changes
Label changes:
No label changes.
Label justifications:
P3: This is a speculative infrastructure optimization without a demonstrated current workflow failure.impact:other: The proposed benefit concerns worker provisioning cost and throughput.
Evidence reviewed
What I checked:
- Current default branch verified: GitHub main and the review checkout both resolve to d2fb381; the checkout remained clean. (d2fb381d6f39)
- Fresh checkout provisioning: Execution-mode worker preparation removes the target directory and clones the repository; it does not fork a warmed environment. (
.github/workflows/cluster-worker.yml:384, d2fb381d6f39) - Existing checkout reuse and dependency preparation: The executor accepts an existing clean Git checkout or clones a missing one, then separately installs dependencies with prefer-offline; this supplies no snapshot fan-out. (
scripts/execute-fix-artifact.mjs:2820, d2fb381d6f39) - Cached provisioning baseline: README documents separate planning and execution runners plus Codex, npm, Corepack, and pnpm-store caches; its credential boundary keeps GitHub credentials outside the repair agent. (
README.md:248, d2fb381d6f39) - Checkout integrity constraint: External merge preflight refuses a preexisting target directory before cloning and fetching the exact PR head; regression coverage verifies refusal before Git runs. (
test/preflight-external-pr-merge.test.mjs:888, d2fb381d6f39) - Existing worktree has a distinct purpose: The executor’s detached worktree checks a validation baseline and shares node_modules; it is not an isolated warmed environment for parallel issue workers. (
scripts/execute-fix-artifact.mjs:3206, d2fb381d6f39)
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-reviewcomments, 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-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only. - Maintainers can also comment
@clawsweeper reviewto 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 explainto ask for more context, or@clawsweeper stopto stop active automation.
Reviewed October 11, 2026, 12:54 AM ET / 04:54 UTC.
- added and removed
on Jun 22, 2026
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
This is a textbook consumer of:
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.