In the terminal, parallelism is solved the same way as in the editor - with a separate worktree. A flag starts the agent in its own checkout under the user's trees directory, where trees are laid out by repository and name, while another flag sets the repository root. That separation is worth understanding precisely: one flag determines where the project lies, the other where the edits happen. They are confused most often, and because of that the agent works on a tree other than the one you meant.
The naive scheme is to launch several agents in one directory because in the terminal it costs nothing. The result is the same as in the editor: edits step on each other, and some conflicts are invisible to version control because they are semantic. One agent renamed a function while another added a call to it - there is no textual conflict and the build fails. A tree per task is cheap insurance, and in the terminal it is natural: each agent simply starts with its own flag.
It helps to see both launch variants once. Below are an agent in a new tree for a task and an agent with an explicitly set repository root and a named tree. Named trees are worth making a habit: a name that matches the task saves a minute a day later on the question of what this tree is and whether it can be deleted.
The sign of confused flags is recognizable. The agent reports finished edits, and nothing has changed in the main working directory: the build runs on the old code and the change history is clean. The edits have not gone anywhere - they are lying in a tree you forgot about. So the first question when a report and the observable state disagree is not about the model but about which tree the work happened in.
There is a flag that lets you skip environment preparation in a new tree, and it calls for care. Skipping speeds up the start but makes checks unreliable: tests without installed dependencies will either fail for an unrelated reason or, worse, run against an old state and show a green result that means nothing. Using it is reasonable only where the environment is prepared in another reproducible way, and that fact is written down.
The key distinction here is session versus checkout. Resuming a session restores the conversation: the goal, the decisions made, the history. A tree restores the state of the file system: the branch, the edits, the installed dependencies. Those are two independent axes, and restoring one without the other gives a strange picture: the agent remembers the intent but does not see its own code, or sees the code and does not remember why it is like that.
Hence a practical reproducibility technique: keep together the session identifier, the commit or the tree, the model and the check commands. Four values fit into one line of a note but turn yesterday's work into something reproducible. Without them, returning to a task a week later starts with archaeology: which branch it matched, which model produced it and what you verified it with - and restoring that from the conversation alone usually does not work.
The technique has a limit of applicability. A tree costs environment preparation and disk space, and in projects with a heavy dependency install that is minutes rather than seconds. For an edit in a single file there is no point in creating one. The threshold is simple: a tree is needed where tasks run in parallel or where a run is long and must not be disturbed by someone else's edits. Everything else is done calmly in the main checkout.
The engineering conclusion is simple: in the terminal isolation is the cheapest, and not using it is strange. One tree per task, a clear name, a prepared environment and a recorded link between session and tree - four habits that remove almost all the questions of parallel work. The rest is ordinary git discipline: merge in time and delete what has served its purpose in time.
The typical failures are predictable. Confusing the repository-root flag with the tree flag and editing in the wrong place. Skipping environment preparation and getting unreliable checks. Resuming a session while forgetting the tree and being surprised by the mismatch. And leaving trees unnamed, then being afraid to delete them.
agent --worktree "upgrade the test runner"
agent --workspace /srv/repos/my-app --worktree auth-fix "fix the flaky auth test"
# --skip-worktree-setup speeds up the start but makes checks unreliable