Atlas shows the red toast Failed to fork session when the fork call against the source session did not succeed, and the underlying cause is usually a session that no longer exists or a session that is busy. Confirm the source session still exists with `atlas session`, wait for it to stop generating because a busy session rejects mutating operations with SessionBusyError, then retry the fork from the session list rather than from a stale timeline view. Atlas's app.tsx catches the failed fork and shows a toast with variant error rather than crashing the TUI, so no work is lost.
Why does the Atlas TUI say Failed to fork session
The Atlas TUI says Failed to fork session because the fork call against the source session did not succeed. app.tsx catches the failed call and shows a toast with variant error rather than crashing, and there are 2 usual causes: a session that no longer exists, or a session that is busy.
Forking in Atlas copies a session so you can branch a conversation without disturbing the original. That operation needs a live, quiet source session. If the source session was deleted, or if you are looking at a timeline view whose session id is stale, the fork has nothing to copy from. If the source session is still generating, the fork is a mutating operation against a busy session and is rejected. Either way, Atlas keeps the TUI alive and tells you with a red toast rather than tearing down your terminal.
How to check whether the source session still exists
Run `atlas session` to confirm the source session still exists before retrying a fork. The Atlas Failed to fork session toast does not distinguish a deleted session from a busy one, so listing sessions is the fastest way to rule out 1 of the 2 usual causes.
If `atlas session` does not list the session you were trying to fork, the session is gone and no retry will help. Start a fresh session instead. If `atlas session` does list it, the session exists and the failure is more likely a busy source, which points at the SessionBusyError path. Checking with `atlas session` also gives you the current session id, which matters because a stale timeline view in the TUI can be holding an id that no longer resolves.
How to fix a fork rejected by SessionBusyError
A busy Atlas session rejects mutating operations with SessionBusyError, and forking is 1 of those mutating operations. Wait for the source session to stop generating, then retry. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a session can be busy even when the visible timeline looks idle.
The practical fix is patience plus a fresh retry. Let the source session finish whatever it is generating, watch the TUI until the session is no longer producing output, then fork again. Because Atlas can run subagents in parallel background sessions, a session you believe is finished may still be waiting on background work, which is why waiting a beat and retrying is more reliable than hammering the fork action. The caveat is honest: Atlas surfaces the toast, not the SessionBusyError text itself, so busy versus missing is something you infer rather than read.
How to retry the fork correctly
Retry an Atlas fork from the session list rather than from a stale timeline view. The session list re-reads sessions when you open it, so the fork acts on a current session id. In 2026 a timeline view left open across a session change can still hold an id that no longer resolves, which reproduces Failed to fork session.
Navigate back to the session list in the Atlas TUI, select the source session there, and fork from that selection. If the fork still fails from a freshly listed session, and `atlas session` confirms the session exists, the session is most likely still busy. If it keeps failing after both checks, start a fresh session instead of forking: a new session carries no dependency on the source and gets you working again immediately, at the cost of losing the forked context.
How to verify the fork worked
Verify an Atlas fork by confirming no red Failed to fork session toast appears and that the new session shows up in `atlas session`. Atlas app.tsx raises that error toast on exactly 1 condition, a failed fork call, so a silent fork is a successful one and the forked session sits alongside the original.
After a successful fork you have two sessions: the original, untouched, and the fork carrying the copied context. List them with `atlas session` to see both. Work in the fork and the original stays as it was, which is the whole point of forking. If the new session does not appear in the list even though no error toast fired, re-open the session list in the TUI to force a fresh read rather than trusting a view that may be stale.
How to fix it
- 01Confirm the source session still exists with `atlas session`. A session that has been deleted or that never existed cannot be forked.
- 02Wait for the source session to stop generating. A busy session rejects mutating operations with SessionBusyError, and a fork is a mutating operation.
- 03Retry the fork from the session list rather than from a stale timeline view, so the TUI is acting on a session id it has just re-read.
- 04If the fork keeps failing, start a fresh session instead of forking. A new session is not blocked by the state of the old one.
- 05Watch for the toast: a successful fork produces no error toast, so the absence of Failed to fork session is the confirmation.
Frequently asked questions
- Why does Atlas show Failed to fork session?
- The fork call against the source session failed. The usual causes are a session that no longer exists or a busy session, which rejects mutating operations with SessionBusyError. Atlas shows a red toast instead of crashing the TUI.
- How do I check if an Atlas session still exists?
- Run `atlas session` to list sessions. If the session you tried to fork is not listed, it no longer exists and retrying the fork will not help, so start a fresh session instead.
- What is SessionBusyError in Atlas?
- SessionBusyError is what a busy Atlas session returns when a mutating operation is attempted against it. Forking is a mutating operation, so a session that is still generating will reject the fork.
- Does Failed to fork session mean I lost my work?
- No. Atlas's app.tsx catches the failed fork call and shows a toast with variant error rather than crashing the TUI. The source session is untouched and nothing is deleted.
- Why does forking work from the session list but not the timeline?
- A stale timeline view can hold a session id that no longer resolves. Retry the fork from the session list rather than from a stale timeline view so the TUI acts on a session id it has just re-read.
- The fork keeps failing. What should I do?
- If the fork keeps failing after checking `atlas session` and waiting for the source session to stop generating, start a fresh session instead of forking. A new session carries no dependency on the source session.
- Can I fork an Atlas session while it is still generating?
- No. Wait for the source session to stop generating. A busy session rejects mutating operations with SessionBusyError, and a fork is a mutating operation.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with Qwen2.5-Coder 32B (Ollama): the air-gapped ceiling in 2026
Qwen2.5-Coder 32B (Ollama) in Atlas: 20GB of weights, roughly 22GB to serve on a 24GB card, 32K tokens (32,768) of context, Free (self-hosted), fully air-gapped.
Atlas for Fastify in 2026
Atlas is a terminal-native AI coding agent for Fastify in 2026. It reads plugin encapsulation and JSON schemas, then runs node --test behind a permission prompt.
Atlas with GPT-OSS 120B (local via Ollama): Offline Reasoning for Air-Gapped Work in 2026
GPT-OSS 120B is the strongest fully offline reasoning model for Atlas: a 65GB MXFP4 download, 131,072 token context, free self-hosted, or $0.15 / $0.60 per Mtok on Groq.
Atlas with DeepSeek-R1 (local via Ollama): Visible Reasoning at Every Size in 2026
DeepSeek-R1 runs locally from 1.5B to 671B under one Ollama tag, with a 128K to 164K context, free self-hosted, or $1.35 / $5.40 per Mtok via Bedrock. Atlas setup.
Atlas with Gemini 3.1 Pro: Setup, Cost, and Tradeoffs in 2026
Run Atlas on Gemini 3.1 Pro in 2026: a 1,048,576 token window at $2 / $12 per Mtok, with real setup steps, the 65,536 output ceiling, and when to switch models.
Atlas with NVIDIA Nemotron 3 Ultra 550B A55B in 2026
Run Atlas on NVIDIA Nemotron 3 Ultra 550B A55B in 2026. A 550B mixture of experts with 55B active, 1,000,000 tokens on NVIDIA NIM at $0.50/$2.50 per Mtok.
Atlas for Expo: Terminal-Native AI Coding for expo-router and Config Plugins in 2026
Atlas is a terminal-native AI coding agent for Expo apps in 2026, covering expo-router file routes, config plugins, and EAS build profiles with diff-first review.
Atlas with Magistral 24B (Ollama): A Local Reasoning Model for the Plan Agent in 2026
Run Atlas on Magistral 24B (Ollama): Mistral's 14GB reasoning model with a 39K context, free self-hosted. Use it as the plan agent, then hand edits to a coder.