Background Coding Agents Without Lock-In: Recreating the Cursor Pattern with Git Worktrees

Background Coding Agents Without Lock-In: Recreating the Cursor Pattern with Git Worktrees#

Background coding agents are one of the most useful ideas in modern AI coding tools.

The pattern is simple:

Instead of asking an agent to mutate your current working tree while you watch, send a scoped task to an isolated branch and review the result later.

Cursor popularized this workflow for many developers. But the underlying primitive is not proprietary.

You can recreate most of the useful pattern with plain git worktrees, task packets, trace logs, and review gates.

That is what we built.

The problem with the local single-branch loop#

Most AI coding starts like this:

You: change this feature
Agent: edits files in your current branch
You: run tests, inspect diff, ask for fixes
Agent: edits again

This is fine for small changes.

It gets messy when the task is long-running:

• dependency migrations;
• multi-file refactors;
• test generation across a repo;
• exploratory fixes where the first approach may fail;
• parallel implementation attempts;
• work you want to review after meetings or overnight.

The core issue is not the model. The issue is workspace coupling.

A background agent should not be able to quietly corrupt your active branch.

What a background coding agent actually needs#

Strip away product UI and the workflow has five parts:

1. Isolation — a separate branch or worktree.
2. A task packet — scope, constraints, commands, and done criteria.
3. Async execution — the agent can work while you do something else.
4. A trace — what happened, where, and when.
5. A review gate — inspect diff and evidence before merge.

You do not need a new mental model for this.

You need a safer wrapper around normal git.

Reproduction: git worktree background agent launcher#

We created a small reusable tool:

tools/agent_workflows/agent_worktree_launcher.sh

It generates a background-agent workspace with:

generated/cursor_background_agents_20260604/worktree_reproduction/
├── README.md
├── trace.jsonl
├── commands/
│   ├── create-worktree.sh
│   └── review-before-merge.sh
└── packets/
    └── 01-background-agent.md

The demo command:

tools/agent_workflows/agent_worktree_launcher.sh \
  --repo . \
  --task "Add async billing export validation in an isolated background branch" \
  --base main \
  --out generated/cursor_background_agents_20260604/worktree_reproduction \
  --mode dry-run

We used dry-run for the published demo because it is safer: it creates the packet and command files without mutating the repo.

When you are ready to create the actual worktree, switch to:

tools/agent_workflows/agent_worktree_launcher.sh \
  --repo . \
  --task "Add async billing export validation in an isolated background branch" \
  --base main \
  --out generated/cursor_background_agents_20260604/worktree_reproduction \
  --mode create

What the packet gives the agent#

The generated packet tells the agent:

Work only inside this git worktree:

generated/cursor_background_agents_20260604/worktree_reproduction/worktrees/add-async-billing-export-validation-in-an-isolated-background-branch

It also requires:

• summary of changes;
• files touched;
• test/build commands run;
• risks and assumptions;
• diff or git diff --stat;
• merge recommendation: merge, request changes, or abandon.

This matters because background work is dangerous without explicit boundaries.

A background agent is useful only if it returns reviewable evidence.

Review gate before merge#

The generated review command is deliberately boring:

git -C "$WORKTREE_DIR" status --short
git -C "$WORKTREE_DIR" diff --stat "$BASE"...HEAD
git -C "$WORKTREE_DIR" diff "$BASE"...HEAD > review/diff.patch

That boring step is the safety layer.

No matter which agent produced the branch, the merge decision should be based on:

• the diff;
• tests;
• logs;
• screenshots or API outputs when relevant;
• explicit unresolved risks.

Do not merge a background agent branch because the final message sounds confident.

Merge it because the evidence is good.

Where Crazyrouter fits#

Background agents multiply model calls.

A single async task may include:

planner call
implementation calls
review call
fix calls
verification summary

If you run everything through one expensive model, cost grows quickly. If you route everything to the cheapest model, failures and retries grow quickly.

A gateway lets you route by step:

With Crazyrouter, the base URL stays OpenAI-compatible:

https://cn.crazyrouter.com/v1

That means the workflow can be used from Cursor, Claude Code wrappers, Codex-style scripts, OpenClaw, CI jobs, or custom tooling.

Background agents vs dynamic workflows#

Background agents and dynamic workflows are related, but not identical.

A background agent is mostly an execution isolation primitive.

A dynamic workflow is an orchestration primitive.

You can combine them: launch a dynamic workflow inside a background worktree, then review the final branch before merge.

A practical rule#

Use a background agent when all three are true:

1. the task can be expressed as a clear packet;
2. the work can happen in an isolated branch;
3. the final result can be judged by diff + tests + evidence.

Do not use a background agent when:

• the task needs constant product judgment;
• the repo is too dirty to isolate safely;
• secrets or production credentials are required;
• no one will review the diff.

Background agents are not a replacement for review.

They are a way to make reviewable work happen asynchronously.

The reusable tool#

The tool is intentionally small:

tools/agent_workflows/agent_worktree_launcher.sh

It does four things:

1. creates a task packet;
2. creates worktree/review commands;
3. writes a JSONL trace;
4. optionally creates the git worktree in create mode.

That is enough to reproduce the core Cursor-style background-agent pattern without locking your workflow to one product UI.

Final takeaway#

The important idea behind background coding agents is not “let an AI code somewhere else.”

The important idea is:

isolate async work, make it measurable, and require evidence before merge.

Git worktrees give you the isolation.

Task packets give the agent boundaries.

Trace logs give you observability.

Crazyrouter gives you flexible model routing across planning, coding, review, and verification.

That is the workflow worth keeping.

Try it#

Use Crazyrouter as an OpenAI-compatible gateway:

https://cn.crazyrouter.com/v1

Learn more:

• Website: https://crazyrouter.com?utm_source=blog&utm_medium=article&utm_campaign=background_agents_git_worktrees
• Telegram: https://t.me/crzrouter?utm_source=blog&utm_medium=article&utm_campaign=background_agents_git_worktrees
• X/Twitter: https://x.com/metaviiii?utm_source=blog&utm_medium=article&utm_campaign=background_agents_git_worktrees