# Sprowt Harness can now keep working on a pull request

By Horia Jurcut · 1 October 2026

Sprowt Harness can now publish a codemod as a pull request and keep working on it. I can ask for another round of edits on the same PR, or close the environment with a saved checkpoint and reopen it later.

In [the previous post](https://minimumeffort.dev/blog/sprowt-harness-can-now-make-a-change), Codex worked on a copy of my project in a Linux VM. The harness reran its checks, then I reviewed the diff before applying the changes locally. I’ve now added a Git workflow around that execution loop.

## Keep working on the same PR

Each codemod, a feature or fix with its own conversation and plan, now has a Git branch and worktree. The worktree is a separate checkout on that branch. Codex edits a copy inside the VM; Git operations stay on the Mac.

Once the tasks and combined checks pass, I can review the diff and confirm publication. The harness commits and pushes the checked source, then creates a PR. Publication is blocked if the source has changed since verification.

Publishing keeps the VM, worktree and conversation. If I ask for an edit, the harness makes a new plan for that round and reuses the environment, including its installed dependencies. After the new checks pass, I can publish the update to the same PR.

The diff shows the full change from the codemod’s starting point. Outside edits to the worktree or published branch block publication until they’re reconciled. A merged or closed PR needs a new codemod.

Before starting that next codemod, the harness fetches the project’s remote branch and safely fast-forwards the local branch. This brings merged changes into the next plan. Local edits stay in the original checkout; overlapping changes or divergent history stop setup. The new codemod uses committed source.

## Save progress without publishing

Closing a codemod saves a local checkpoint and removes its VM. This also works for unfinished work, without creating a PR or needing GitHub.

The harness exports the latest source and commits the checkpoint before deleting the VM. It checks that the saved source matches the export. If saving fails, it retains the VM and recovery state for a retry.

The conversation, plan, draft and queued instructions stay saved. Reopening restores the worktree, and the next execution creates a fresh VM. The source survives; the old runtime and installed dependencies need setting up again.

Closed worktrees are retained for 30 days by default. After that, the harness can prune an unchanged checkout while keeping its branch and saved history. Reopening recreates it. Outside edits prevent pruning.

Keeping the VM after publication makes repeated edits cheaper. Closing releases that environment while keeping a recoverable version of the work. Closing or deleting a local codemod leaves its GitHub PR unchanged.

## Current limits

This workflow still uses one executor per codemod, with checks rerun by the harness. It doesn’t yet have an independent review worker. Multiple Codex and Muse workers on one change are still planned.

Execution uses Linux, so native iOS and macOS builds still need a future macOS VM backend.