Guide · Updated 1 October 2026 · Mirven
Short answer. Give every script job its own Git worktree, decide which folders each agent owns before it starts, let only one agent at a time touch scenes, prefabs and shared assets, check every job with a real batchmode build and tests, and have the work reviewed by a different model than the one that wrote it. Do not put a single "manager" agent in the middle of everything.
What goes wrong when agents share a Unity project
- Scenes and prefabs collide. Unity serializes scenes, prefabs and many assets as large YAML files. Two agents changing the same scene produce conflicts that a text merge cannot resolve safely, even with Unity's Smart Merge (UnityYAMLMerge).
- .meta files and GUIDs drift. Every asset has a .meta file with a GUID that other assets reference. If two agents create or move the same asset in different branches, the GUIDs differ and references break after the merge.
- One editor per folder. The Unity Editor locks a project folder while it is open. Agents cannot share one open project to build or test at the same time.
- The manager agent stalls. The common fix is one orchestrator agent that hands out work and reads every report. Its context fills with everyone else's news until it forgets, repeats itself and stops.
- "Done" is not done. An agent reporting success is a claim. Without a compile, tests and a build, broken code reaches main.
1. Set the project up for text merges
In Project Settings, keep Asset Serialization on Force Text and Version Control on Visible Meta Files. Commit every .meta file together with its asset. Keep Library/, Temp/, Logs/ and UserSettings/ out of Git.
2. One Git worktree per script job
A worktree is a second working folder on its own branch, sharing the same repository. Each agent gets a folder it cannot trample:
git worktree add ../mygame-combat -b agent/combat git worktree add ../mygame-ui -b agent/ui
Each worktree is a separate Unity project folder with its own Library/, so its first open or batchmode run reimports assets. On a large project that costs time and disk; plan for it, and remove finished worktrees with git worktree remove.
3. Decide who owns which folders, before anyone starts
Write the plan down: for each job, the folders it will touch and what "done" means. Two jobs that name the same folder do not run at the same time. Assembly definition files (.asmdef) per feature folder help further: they keep a change in one area from forcing recompiles and errors in another.
4. Scenes, prefabs and shared assets take turns
Run script jobs in parallel, but give scene, prefab and shared asset work a single lane in the main project, one job at a time. Splitting a level into additive scenes and building with small prefabs reduces how often jobs wait on each other.
5. Check every job with a real build
Run checks headless, in the job's own worktree, so they do not need the open editor:
Unity -batchmode -projectPath ../mygame-combat -runTests -testPlatform EditMode -testResults results.xml Unity -batchmode -quit -projectPath ../mygame-combat -executeMethod BuildScript.Build -logFile build.log
A job is done when its compile, tests and build pass, not when the agent says so. Send a failed check back to the same agent with the error first.
6. Review with a different model
A model reviewing its own code tends to approve it. Have Codex review what Claude Code wrote and the other way round, and merge only after a person has read the result.
7. Replace the manager with a plan
Instead of one agent reading every report, give each agent only its job, its folders, its finish line and the few project notes it needs. Coordination lives in the written plan, where you can read it, not in one model's context window.
Doing it by hand vs. with Mirven
Everything above works with plain Git, Claude Code, Codex and a few scripts; ours are on GitHub, MIT: unity-parallel-agents. Mirven is a desktop app that does it for you: Astra, its planner, turns one request into jobs with named folders and finish lines; script jobs run in their own worktrees; scene and asset jobs take turns; every job is checked with tests, a real Unity build and a review by a model that did not write it; project memory gives each job only the notes it needs; and nothing merges until you say yes. It runs on your own machine with your own Claude Code or Codex account, and it is in free private beta.