Git worktrees for every chat

Running two agents against the same checkout is a recipe for conflicts. One edits a file while the other reads a stale version, builds collide, and you end up untangling changes that were never meant to mix.

Zuse Alpha gives every chat its own git worktree. The branch is isolated, the working directory is isolated, and the agent in that chat sees only its own changes.

Why worktrees

A worktree is a real, native git feature: a second checkout of the same repository on its own branch, sharing one object store. Zuse Alpha creates one per chat automatically, so you get isolation without cloning the repo or copying files.

• Run several agents on the same project at once.
• Keep an experimental refactor separate from a quick fix.
• Throw away a worktree if the approach did not pan out, with no impact on your main checkout.

Review and merge on your terms

Each chat's changes show up in the PR / Changes pane with a diff viewer and commit composer. When you like what an agent did, commit it from there and merge the branch. When you do not, discard the worktree and move on.

Isolation is the default, not something you have to remember to set up.

Why a shared checkout breaks down

Most developers have a familiar mental model for working alone: one repository checkout, one current branch, one set of local changes. That works when a single person is moving through one task at a time. It starts to fail when agents make parallel work cheap. You can ask one agent to fix a flaky test, another to explore a refactor, and another to update documentation. If they all operate in the same working directory, the checkout becomes a collision point.

The first problem is file edits. One agent may read a file, plan a change, and then write it after another agent has already modified the same section. Even if the final file is syntactically valid, the reasoning that produced it may be stale. The second problem is command state. Build artifacts, generated files, package-manager installs, and test watchers can interfere with each other. The third problem is review. When all changes land in one working tree, you lose the clean connection between a conversation and the diff it produced.

Humans can sometimes manage this manually by stashing, branching, cloning, or carefully sequencing work. Agents make the manual approach too fragile. If the product encourages parallel sessions, isolation has to be the default infrastructure rather than a discipline the user remembers under pressure.

Worktrees are native git, not a Zuse Alpha invention

Git worktrees solve this with a feature that already exists in git. A worktree is another checkout of the same repository, usually attached to a different branch, while sharing the underlying object database. It is lighter than cloning because it does not duplicate the full repository history, and it is safer than sharing a single checkout because each worktree has its own working directory and index.

Zuse Alpha uses that native mechanism instead of inventing a separate file-copy system. When a chat gets a worktree, git still understands what is happening. You can inspect the branch from the command line, use normal git commands, run your usual tooling, and merge or delete the branch with standard workflows. The app adds automation and visibility around a real version-control primitive.

This matters for trust. Developers already know how git branches behave. They know how to review diffs, resolve conflicts, and throw away an experiment. A product-specific isolation layer would have to earn that trust from scratch. Worktrees let Zuse Alpha integrate with the grain of the tools teams already use.

One chat, one branch, one story

The product model is simple: a chat represents a unit of work, and that unit of work has its own branch and working directory. The agent in that chat can inspect files, make edits, run commands, and iterate without stepping on another chat. The human can return later and see both the conversation and the resulting diff in the same context.

That connection is more important than it sounds. Reviewing agent work is not only about whether the diff compiles. You often need to know why the agent chose a particular approach, what alternatives it considered, which tests it ran, and where it saw uncertainty. If the chat and the branch stay paired, the review story is coherent. If the diff is mixed with unrelated changes from other sessions, the story falls apart.

Worktrees also make failure cheaper. If an agent takes a bad direction, you can discard the worktree without cleaning up your main checkout. If two agents produce competing solutions, you can compare them as separate branches. If one session is a long-running refactor and another is an urgent fix, the fix does not need to wait for the refactor to settle.

Parallelism changes the role of review

When agents can work side by side, the developer's job shifts from doing every mechanical step to steering, sampling, and reviewing. That makes clean boundaries essential. You need to be able to ask: what did this session change, and only this session? Which tests did it run? Which files did it touch? Does this branch deserve to be committed, revised, or deleted?

A shared checkout makes those questions harder because unrelated changes become entangled. Worktrees make them ordinary. The changes pane can show the diff for the current chat. The commit composer can focus on the branch tied to that chat. The developer can inspect one attempt at a time instead of untangling a blended working directory.

This is especially useful for exploratory work. Suppose you are not sure whether a bug belongs in the UI, server, or persistence layer. You can ask separate agents to investigate different hypotheses. One might find the real root cause. Another might produce a useful test even if its fix is wrong. Another might confirm that a path is a dead end. Isolated branches let you keep the useful parts without treating every exploration as a permanent mutation of your checkout.

Conflict does not disappear, but it moves to the right place

Worktrees do not magically eliminate merge conflicts. If two branches edit the same code, git will still ask you to reconcile them. That is good. The conflict appears at integration time, where you can make a deliberate decision, rather than silently during two agents' file writes. The difference is that each branch remains internally understandable.

This mirrors how teams already collaborate. Two engineers can work on separate branches and handle conflicts when one branch lands after the other. The branch boundary does not remove all coordination costs, but it preserves intent. Zuse Alpha applies the same pattern inside a single developer's agent workflow.

It also makes sequencing easier. You can land the small fix first, rebase the refactor worktree, and ask the agent to adjust. You can keep a risky experiment around while continuing normal work elsewhere. You can delete stale attempts once the chosen branch merges. The cleanup steps are git steps, not mysterious app-specific recovery.

Why not clone for every chat?

Cloning per chat would provide isolation, but it is heavier and clumsier. Large repositories can take time to clone and consume significant disk space. Private repositories may require repeated authentication. Local configuration, submodules, and package caches can become inconsistent. Worktrees avoid much of that overhead by sharing the repository's object store while keeping separate working directories.

There are still costs. A worktree has files on disk, can produce build artifacts, and may require dependencies to be installed depending on the project. But it is a better baseline for frequent parallel sessions than full clones. It gives the app a fast path to create isolated work without making the user's machine feel like it is filling with duplicate repositories.

The native git foundation also keeps escape hatches open. If you want to inspect a worktree in your editor, you can. If you want to run a command manually in that directory, you can. If you want to manage the branch from the terminal, git recognizes it. Zuse Alpha is not asking you to abandon the workflows you already trust.

A calmer way to use more agents

The point of worktrees is not to make the UI look organized. It is to make parallel agent work safe enough to become normal. Without isolation, every additional agent increases the chance of accidental interference. With one worktree per chat, additional agents create additional branches with clear boundaries.

That changes how you can use the tool. You can let a long task run while starting a short one. You can compare providers on the same issue. You can ask for a conservative fix and a more ambitious refactor, then choose. You can preserve your main checkout as the stable place you return to, instead of letting every agent experiment accumulate there.

Zuse Alpha makes this the default because the workflow should protect you before you remember to protect yourself. Agents are most useful when they let you explore more options. Git worktrees make that exploration reviewable, reversible, and compatible with the version-control habits developers already have.