# Atlas TUI error: Failed to fork session > Confirm the source session still exists with `atlas session`, wait for it to stop generating, then retry the fork from the session list. 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. ## Symptom A red toast appears in the Atlas TUI reading: Failed to fork session. The TUI keeps running, the fork does not happen, and the session you tried to fork from stays exactly as it was. ## Cause The fork call against the source session failed. Atlas's app.tsx catches the failed fork call and shows a toast with variant error rather than crashing the TUI. The underlying cause is usually a session that no longer exists, or a busy session, which rejects mutating operations with SessionBusyError. ## Fix 1. Confirm the source session still exists with `atlas session`. A session that has been deleted or that never existed cannot be forked. 2. Wait for the source session to stop generating. A busy session rejects mutating operations with SessionBusyError, and a fork is a mutating operation. 3. Retry 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. 4. If the fork keeps failing, start a fresh session instead of forking. A new session is not blocked by the state of the old one. 5. Watch for the toast: a successful fork produces no error toast, so the absence of Failed to fork session is the confirmation. ## 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. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/tui-fork-session-failed Source of truth: aeo_pages row `/resources/troubleshooting/tui-fork-session-failed` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.