Put two agents in one checkout and sooner or later they edit the same file. overvibe new --worktree gives each helper its own git worktree, on a new branch ov/<name> made from your HEAD. When a helper stops, the session that started it gets the branch, the commit count, any uncommitted files and the command to merge it.

One session rewrites a file the other is halfway through, or runs the tests on a mix of both changes. Then you spend the afternoon working out which hunk came from which agent.
Build the CSV export and the login rate limit in parallel, each in its own worktree, and merge them when they're done.
Features that don't depend on each other. Two or three is a good start.
Started with --worktree and --attach, so each sits under the coordinator on its own branch.
Your own checkout stays where you left it, and you can keep working in it.
Branch, commits, uncommitted files and the merge command arrive in the coordinator.
With the tests between merges. The worktree and branch stay until you or the coordinator remove them.
Behind it, one flag per helper. The coordinator adds --worktree whenever two helpers would edit the same repo. Codex helpers take it too. Read the CLI reference
$ overvibe new --attach --worktree --cwd . --name "shop: csv export" \ --prompt "Add CSV export to the orders page and commit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<summary>\"" $ overvibe new --attach --worktree --tool codex --cwd . --name "shop: rate limit" \ --prompt "Add a rate limit to POST /login and commit. When done, run: overvibe send \"$OVERVIBE_SESSION\" \"<summary>\""
there's one feature, or the second job only reads. A reviewer that leaves your files alone can share your checkout, and one agent on one branch is easier to follow than three.
Beside the repo, in <repo>.worktrees/<name>, each on a new branch ov/<name> from the folder's HEAD.
You do, or the coordinator once you say so. Overvibe never deletes a worktree or a branch on its own.
A session can have 8 running children by default, 3 levels deep. Settings > Spawn limits changes both. Sessions you start yourself aren't capped.
A big refactor or migration split by module, one helper per area in its own worktree, and a reviewer reading the merged result.
Code reviewClaude writes the change, Codex writes the tests and agy reads the diff. All three answers land in one session.
Plan reviewClaude writes the plan, Codex reads it with the repo open and pushes back, all before a line of code exists.
Install Overvibe, start a coordinator in your repo, and ask it for one worktree per feature.
