Git worktrees
Run agents in their own git worktree so several can work on one repository in parallel
Run an agent in its own git worktree instead of your checkout. Several agents can then work on the same repository at once without touching each other's files, or yours. Worktrees work with both the native and the Docker sandbox backend.
stashbase agent run --profile coding --worktree -- claudeTo make it the default for a profile:
[workspace]
worktree = truePass --worktree=false to skip the worktree for a single run.
How a run is laid out
Each run gets a readable name such as amber-river-storm:
- Worktree:
.stashbase/worktrees/amber-river-storminside the repository. It is visible in your IDE and hidden fromgit status. - Branch:
stashbase/amber-river-storm, started from whatever you have checked out.
The agent's working directory is the worktree, so its edits and commits never land in your checkout.
Review, merge, and clean up
Everything below happens locally. Nothing is pushed.
stashbase agent worktrees list # status and commits not merged yet
stashbase agent worktrees merge amber-river-storm # git's own merge message
stashbase agent worktrees clean # remove merged agent work
stashbase agent worktrees remove amber-river-storm # discard one run| Command | Options |
|---|---|
worktrees merge <name> | --squash to squash, -m to set the message, --keep to keep the worktree after merging. |
worktrees clean | Removes merged agent work. --all removes everything. |
worktrees remove | Discards one run (alias: delete). --keep-branch keeps its branch. --all discards all runs; it asks first unless you pass --yes. |
merge refuses while there are uncommitted changes and stops on conflicts without losing anything.
Continue a run
Resume a previous run by name:
stashbase agent run --profile coding --resume amber-river-storm -- claudeStashbase reuses the worktree if it was kept, including uncommitted work, or recreates it from the run's branch.
Safety
- Docker backend: the container sees only the agent's worktree and the repository's
.git, never your checkout. Git config, hooks, submodule configs, your checkout'sHEADandindex, and the worktree's own config are read-only. - Native backend: the same git files and the rest of your checkout are added to the run's
deny_write. - After every run, Stashbase restores the worktree's git pointer files, restores deleted branches and tags, and resets rewritten ones. Commits and branches the agent created during the run are kept, with a warning listing them.
- Locking: a worktree is locked while a run is in progress, so
merge,clean,remove, and plaingit worktree removenever delete one under a working agent. Leftovers from killed runs are verified before any git command runs in them, and shown asUNSAFEif anything looks tampered with.
Limitations
- Docker-backend worktrees are not supported on Windows yet. Such a profile fails validation with a clear message.
- The agent can write the repository's shared object store, because it needs to in order to commit. This is the same as in runs without a worktree.
- With the native backend, the agent can still create new top-level files in your checkout, but not modify existing ones.