The Read-Only Worktree Gate for AI-Generated Patches

Why this is worth reading: You keep reviewing AI-generated patches by reading the diff, but the expensive failures are rarely the lines you can spot. They are the patches that apply cleanly, pass your eyeball, and then break the first local command you run. This guide gives you a read-only git worktree smoke gate that applies a candidate patch in a separate directory, runs one safety command, and discards the worktree when it finishes. You also get a decision table for deciding when to move the same command to a free server option instead of your laptop.

You start with a constraint that changes how you treat any generated patch: a diff is an untrusted artifact until it has been proven in a live checkout. Reading a diff tells you whether the change is syntactically plausible. Running a command after applying the diff tells you whether the change preserves the one behavior you care about. If you skip that second step, you ship untested reasoning and pay for it later with flaky merges, broken local builds, and emergency reverts.

When you use MonkeyCode's free model access, the same rule applies. Generate the patch, save it as a unified diff file, and treat that file as a patch to validate rather than a change to merge directly. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free server option is useful later as an isolated runner, but it should not remove the read-only gate from your own workflow.

The failure mode: a diff that applies is not a patch that works

You have probably seen a patch that looks correct in a code review and still fails when you run it. The change moves a function, changes an import, or edits a fixture, and the diff itself contains no indication that the test command will fail. A diff is a representation of change, not a proof of behavior. So the first question to answer with any generated patch is not "does this look right?" but "does this still run after I apply it?"

The second failure mode is workspace contamination. If you apply the patch to your main working tree, run one test, and then want to continue editing, you now have generated changes mixed with your own in-progress work. You either commit earlier than you wanted, stash, or manually clean up. A disposable worktree separates those states so the patch never touches your branches until it has passed the smoke command.

A disposable git worktree smoke gate

You can implement the gate with a small shell script. The script takes a patch file and the test command as arguments. It creates a detached worktree from HEAD, applies the patch there, runs your command, and removes the worktree in a trap. This keeps your current branch untouched even if the command fails.

#!/usr/bin/env bash
set -euo pipefail

if [[ $# -lt 2 ]]; then
  echo "usage: $0 <patch-file> <test-command> [args...]" >&2
  exit 1
fi

PATCH_FILE="$1"
shift
TEST_CMD=("$@")

WORKTREE_DIR=$(mktemp -d ".smoke-wt-XXXXXX")
trap 'git worktree remove --force "$WORKTREE_DIR"' EXIT

git worktree add --detach "$WORKTREE_DIR" HEAD
git -C "$WORKTREE_DIR" apply --check "$PATCH_FILE"
git -C "$WORKTREE_DIR" apply "$PATCH_FILE"

(
  cd "$WORKTREE_DIR"
  printf 'Running: %s\n' "${TEST_CMD[*]}"
  "${TEST_CMD[@]}"
)

printf 'Smoke passed: %s\n' "$WORKTREE_DIR"

You run it with a patch file plus a command. For example:

./smoke-gate.sh /tmp/candidate.patch pytest -q tests/unit
./smoke-gate.sh /tmp/model.patch npm test

The important detail is that the script receives the test command as an array, not as a single string. That preserves arguments such as -q tests/unit without making you build a shell string. You still should not feed an untrusted command into the script; the script trusts the command you pass.

A go/no-go table for choosing the runner

You do not need to use a free server for every patch. Use the lightest execution context that can answer your one question.

Condition	Local disposable worktree	Free server option
Your smoke command is fast and read-only	Yes	Optional
Your local machine lacks a required service or dependency	No	Yes, if available for your account
You want to inspect generated files or logs immediately	Yes	Less convenient
The patch may access files outside the repository	Not enough on its own	Not enough on its own
You need a full CI-level check, lint, or security scan	No	No

You can attach this table to a merge checklist so the gate does not become a personal habit that disappears under deadline pressure.

Where the free server option fits

If MonkeyCode's free server option is available for your account, use it as an execution target for the same smoke command, not as a replacement for the patch-first rule. The principle stays the same: apply the patch to a separate copy, run one command, and observe the result. The free server is useful when the command would otherwise require a service you do not want to run locally, when your laptop is already busy, or when you want a repeatable environment for the check.

Keep the command definition small and explicit. A useful smoke command is one that exits nonzero on a real failure and does not depend on interactive input. For a Python project, pytest -q tests/unit is a reasonable first signal. For a Node project, npm test -- --runInBand is better than a watcher-based command that never exits. If the command requires a secret, do not pass it in the patch file; inject it through the execution environment.

Limitations and who should skip this

The worktree smoke gate is a first-pass fitness check, not a full review or CI pipeline. It does not prove that the patch is correct, safe, or aligned with the system design. It proves only that one command passes after applying the patch.

You should skip this approach if your project already has a strict requirement for human review before any branch runs, if your repository cannot cleanly support multiple worktrees, or if your smoke command has side effects that can escape the worktree. A test that writes to a system directory, sends notifications, or mutates a shared database can still affect an environment even when the working tree is disposable. In those cases, run the check inside a container or on a dedicated free server environment instead of your development host.

The smallest habit that makes this stick

You do not need to adopt every step at once. Decide in advance what your one smoke command is, and refuse to merge any generated patch until that command has passed in a disposable worktree. The habit will outlive whichever model or free server you use. If the first run fails, keep the worktree around long enough to read the failing output, then let the trap clean it up after you have recorded the result.