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 SeaShell in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install SeaShellRelated guides
Atlas with Qwen2.5-Coder 14B (Ollama) in 2026
Explore Atlas with Qwen2.5-Coder 14B (Ollama), a powerful local model for AI coding agents in 2026. Get free, self-hosted performance with a 32K token context window.
Atlas with Qwen3-Coder 480B-A35B Instruct in 2026
Explore Atlas with Qwen3-Coder 480B-A35B Instruct, Alibaba's 480B parameter coding model. Ideal for agentic SWE-bench tasks, offering a 256K token context window for complex codebases.
Atlas with Mistral Nemo in 2026
Drive Atlas with Mistral Nemo, the 12B open-weights model from Mistral AI. Leverage its 128,000 token context window and efficient Tekken tokenizer for coding tasks in 2026.
Atlas with Kimi K2 Turbo in 2026
In 2026, Atlas developers can drive highly interactive coding sessions with Kimi K2 Turbo, offering a 256K token context window and responsive performance at $2.40/Mtok input and $10.00/Mtok output.
Atlas vs Crush: Terminal AI Coding Agents in 2026
Atlas and Crush, two terminal AI coding agents for 2026, offer distinct approaches. Atlas provides a TUI with permission-gated tools and diff review, while Crush focuses on LSP integration and mid-session model
Atlas with Gemini 3 Flash in 2026
Discover Gemini 3 Flash as the default model for Atlas in 2026. Leverage its 1M token context window and cost-effective pricing for efficient AI coding agent loops.
Atlas with Kimi K2 Thinking Turbo in 2026
Drive Atlas with Kimi K2 Thinking Turbo in 2026 for priority reasoning and a 256K token context window, ideal for interactive coding. Understand its $8.00/Mtok output cost.
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.