Mistral Vibe Adds Tools to Keep AI Coding Tasks Apart

Mistral Vibe, an AI coding assistant, added a built-in tool in its September 9 release for managing Git worktrees: separate working folders that let coding tasks use different branches of the same project. Version 2.25.1 also adds desktop retention controls for those folders. For developers giving an AI several jobs, the practical issue is keeping one task’s edits out of another task’s way, then preserving anything worth keeping when the session ends.

The interesting part is the bookkeeping around the code. Vibe’s released worktree instructions track which session uses a folder, where its work began and whether removal would discard changes. My reading is that this kind of lifecycle management deserves as much attention as creating the workspace. Starting another coding task is easy to demonstrate. Finishing it without losing track of its work is the more useful standard.

A Separate Folder Has a Specific Job

Git already supports multiple working folders attached to one repository, the project’s version history. Its documentation describes using them to work on different branches simultaneously or try an experiment without disturbing existing development. Vibe is building a managed workflow around that capability, rather than inventing a new form of version control.

Consider a hypothetical developer asking AI to repair a login bug while another task changes the settings page. Separate worktrees give each task its own files to edit. They do not settle whether the two changes fit together. A developer still has to review the resulting changes and check the combined application. Nor does a separate folder, by itself, establish a security boundary around everything the agent can do.

Vibe’s shipped instructions introduce another consequential distinction: a newly created branch starts from the remote repository’s default branch, with a best-effort fetch first, rather than simply copying the current checkout’s position. The inspected code falls back to Git’s default when no remote default can be found. A developer working on an unfinished feature therefore should not assume a new task inherits that feature. The starting point is part of the assignment, because it determines which code the agent sees.

The Work Can Outlive the Session

The released implementation separates checks for explicit cleanup from checks for automatic retention. Its cleanup inspection looks for edited files, new files Git is not yet tracking, and commits made since the worktree’s recorded starting point. A commit is a saved change in Git’s history. Saving one does not necessarily mean the work has reached another machine.

Automatic retention inspects that second question. The code checks for commits that are not present in the locally known remote branches, alongside file changes and untracked files. The release notes say desktop cleanup also skips active worktrees and keeps 15 recent managed Code worktrees by default, with a setting to change that count. This is a retention policy, not a promise that every temporary folder disappears at the threshold.

There is also a recovery mechanism for deliberate removal of unfinished work. In the inspected code, the snapshot function saves tracked changes and untracked files into a Git reference, a named pointer to stored history. It uses a separate staging record so making that snapshot does not alter the worktree’s own staged selection. Ignored files are excluded. A saved reference can help recover code, but should not be confused with a complete backup of everything in the directory.

Useful Design, Still a Limited Finding

These details matter because an apparently tidy workspace can conceal unfinished work. A file can be committed but not shared; a newly created file can exist without being tracked. Treating either state as disposable would mistake organization for completion. Vibe’s inspected checks distinguish them. That is a concrete design choice, rather than evidence that its AI writes better code.

This article examines the published instructions and source at version 2.25.1; it does not report running Vibe or testing recovery. Later release notes list version 2.25.4, so the version examined here is not presented as the latest release. Instructions also do not prove that every interface and interruption follows the intended path. A stronger reliability claim would require trying deletion, crashes and resumed sessions and checking what actually survives.

The limitation does not erase the value of the approach. Separate folders make parallel work easier to reason about; explicit ownership, starting points and recovery records make it possible to reason about the end of that work. For coding agents, a useful completion message should leave the developer able to locate the changes, understand their starting point and decide what to keep.