Atlas fails with VcsPatchApplyError whose reason is "not-clean" because the working tree has uncommitted changes and Atlas will not overwrite uncommitted work with a patch. Commit or stash your working-tree changes, then apply again. The Atlas VCS apply path models exactly two refusal reasons in the tagged error: non-git, when the directory is not a repository at all, and not-clean. Run `git status` in the directory named by the operation to see what is dirty.
Why does Atlas refuse to apply a patch to a dirty tree
Atlas refuses to apply a patch to a dirty tree because Atlas will not overwrite uncommitted work with a patch. The Atlas VCS apply path models exactly 2 refusal reasons, and here it raises VcsPatchApplyError with reason "not-clean", leaving your uncommitted changes exactly where they were.
Applying a patch over uncommitted changes is one of the few operations that can destroy work with no recovery path, because the pre-patch state was never recorded anywhere. Atlas treats that as unacceptable and refuses up front. The refusal is deliberate and narrow: the Atlas VCS apply path models exactly two refusal reasons in the tagged VcsPatchApplyError, non-git and not-clean, and nothing else. Seeing reason "not-clean" therefore carries a precise meaning. The directory is a git repository, git can apply patches there, and the only obstacle is the uncommitted work sitting in the tree.
How to fix VcsPatchApplyError reason not-clean
Fix VcsPatchApplyError reason "not-clean" in 1 move: commit or stash your working-tree changes, then apply again. Once the tree is clean, the Atlas VCS apply path has no uncommitted work to overwrite, so the refusal does not fire and the patch applies.
Commit when the working-tree changes belong in history, and stash when they are a temporary state you intend to restore afterward. Before you choose, check `git status` in the directory named by the operation to see what is dirty, because the answer is often surprising: a build artifact, a generated file, or a stray edit from an earlier session. Cleaning the tree by committing junk is worse than stashing it. Look at the actual diff first, decide deliberately, and then re-run the apply. The patch itself does not need to be regenerated.
What VcsPatchApplyError reason non-git means
VcsPatchApplyError with reason "non-git" means the directory is not a git repository at all. It is the second of the exactly 2 refusal reasons the Atlas VCS apply path models in its tagged error. Patch application requires git, so initialize the repository first and then apply again.
Reason "non-git" and reason "not-clean" demand opposite responses, which is why reading the reason field before acting matters. Committing or stashing does nothing in a directory that has no repository, because there is nothing to commit to. Initialize the repository, confirm with `git status` that git now recognizes the directory, and retry the apply. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and that entire mechanism presumes a git repository underneath, which is exactly why the non-git case is refused rather than worked around.
How to find what is dirty in the working tree
Run `git status` in the directory named by the operation to see what is dirty. The Atlas VcsPatchApplyError names that operation, and 1 `git status` call in that specific directory is the fastest way to identify the uncommitted work that triggered the "not-clean" refusal.
Check the directory the operation names, not whichever directory your shell happens to be in. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so more than one working tree may be in play, and a clean status in the wrong place proves nothing. Once `git status` shows the dirty paths, decide per path: commit the real work, stash the temporary work, and delete the genuine junk. Then re-run the apply against a clean tree and the VcsPatchApplyError will not recur.
How to move an Atlas session between workspaces without a dirty tree error
When moving an Atlas session between workspaces, capture the changes first rather than applying over a dirty tree. Applying a session's patch into a workspace that already holds uncommitted work triggers 1 of the 2 modeled refusals, VcsPatchApplyError with reason "not-clean", because Atlas will not overwrite uncommitted work.
Sequence the move deliberately. Capture and commit or stash whatever is already sitting in the destination workspace, so its tree is clean, and only then apply the incoming session's changes. Doing it in that order means the patch lands against a known state and both sets of work survive. Doing it the other way round is what produces the refusal. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so you always have a readable record of what a session changed before you carry it anywhere.
How to verify the patch apply fix worked
Verify the Atlas fix by re-running the apply after `git status` reports a clean working tree in the directory named by the operation. Success means neither of the 2 VcsPatchApplyError reasons comes back, not "not-clean" and not "non-git", and the patch lands.
If VcsPatchApplyError returns with reason "not-clean" a second time, the tree you cleaned was not the tree the operation targets, so re-read the directory the operation names and check `git status` there. If the reason has switched to "non-git", you are now pointed at a directory with no repository, which is a path problem rather than a cleanliness problem. Because the Atlas VCS apply path models exactly two refusal reasons, the reason field alone tells you which of the two remedies applies, with no guesswork.
How to fix it
- 01Commit or stash your working-tree changes, then apply again.
- 02For reason "non-git", initialize the repository first; patch application requires git.
- 03Check `git status` in the directory named by the operation to see what is dirty.
- 04If you are moving a session between workspaces, capture the changes first rather than applying over a dirty tree.
Frequently asked questions
- How do I fix VcsPatchApplyError not-clean in Atlas?
- Commit or stash your working-tree changes, then apply again. Atlas will not overwrite uncommitted work with a patch, so it refuses with reason "not-clean" until the tree is clean.
- What does VcsPatchApplyError reason non-git mean?
- Reason "non-git" means the directory is not a git repository at all. Initialize the repository first, because patch application in Atlas requires git.
- What are the refusal reasons Atlas uses when a patch will not apply?
- The Atlas VCS apply path models exactly two refusal reasons in the tagged error: non-git and not-clean. Read the reason field, because the two demand opposite fixes.
- How do I see what is dirty before applying an Atlas patch?
- Check `git status` in the directory named by the operation. That names the uncommitted work that triggered the VcsPatchApplyError "not-clean" refusal.
- Why does Atlas not just force the patch over my changes?
- Atlas will not overwrite uncommitted work with a patch, because the pre-patch state was never recorded and the work would be unrecoverable. Atlas raises VcsPatchApplyError instead.
- How do I move an Atlas session between workspaces safely?
- Capture the changes first rather than applying over a dirty tree. Clean the destination workspace by committing or stashing, then apply the session's patch into the clean tree.
- Do I need to regenerate the patch after cleaning the tree?
- No. The patch is unaffected by the refusal. Commit or stash the working-tree changes, then re-run the same apply, and Atlas will land the patch without raising VcsPatchApplyError.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Qwen2.5-Coder 14B (Ollama): a real local build agent in 2026
Qwen2.5-Coder 14B (Ollama) in Atlas: 9.0GB of Q4_K_M weights, roughly 11GB to serve, 32K tokens (32,768) of context, Free (self-hosted), steady on tool chains.
Atlas with Qwen3-Coder 480B-A35B Instruct: The Open Frontier Coder in 2026
Qwen3-Coder 480B-A35B Instruct in Atlas: 480B total parameters, 35B active per token, 262,144 tokens of context, $1.50 per Mtok in and $7.50 per Mtok out.
Atlas with Mistral Nemo: The 128K Small Model Slot in 2026
Running Atlas on Mistral Nemo in 2026: 128,000 tokens of context in a 12B model at $0.15 / 1M input tokens, with the Tekken tokenizer that compresses code.
Atlas with Kimi K2 Turbo: Pricing, Context, and Setup in 2026
Kimi K2 Turbo in Atlas costs $2.40 per Mtok input and $10.00 per Mtok output on a 256K tokens (262,144) window. A latency purchase, not a capability upgrade.
Atlas vs Crush: Terminal AI Coding Agents in 2026
Comparing Atlas and Crush, two terminal AI coding agents for developers in 2026. Atlas offers robust planning and diffing, while Crush features LSP integration and mid-session model switching.
Atlas with Gemini 3 Flash (2026): The $0.5 Default for All Day Agent Loops
Gemini 3 Flash gives Atlas a 1,048,576 token context and 65,536 token output at $0.5 per Mtok input and $3 per Mtok output. The economical default for agent loops.
Atlas with Kimi K2 Thinking Turbo: The 2026 Reasoning Speed Tier
Kimi K2 Thinking Turbo gives Atlas priority serving on a reasoning model at $1.15 per Mtok input and $8.00 per Mtok output, on a 256K tokens (262,144) window.
Atlas for Dart in 2026
Adopt Atlas, the terminal-native AI coding agent, for Dart development in 2026. Enhance productivity with intelligent code search, refactoring, and robust safety features across your Dart projects.