Claude Code failed to load session

Quick fix

1. Open the session on a different folder, or restart the app.
2. Read the log. Open Help, then Troubleshooting, and pick Show Logs in Finder on macOS or Show Logs in File Explorer on Windows. Anthropic documents that route in the section of its desktop page headed "Get Desktop's logs for an SSH problem".
3. Match what you find in the table below, then read that section.

If you would rather go straight to the file: on macOS it is ~/Library/Logs/Claude/main.log, the path three of the reports below quote lines out of. On Windows the folder is %APPDATA%\Claude\logs\, and on an MSIX install that folder may not exist at all.

If the folder looks right and the log says nothing useful, Anthropic's own last step is to check Console.app on macOS, or Event Viewer under Windows Logs > Application on Windows.

What you see or log

The folder

The folder you picked may have been moved or deleted since the session started. This is the first cause Anthropic names, and it is the one no report shows a log line for, so it is where to start when nothing in the table matches.

How to fix it

1. Select a different folder and start the session again.
2. If the folder does exist, restart the app and try it a second time.
3. If it fails the same way, read the log and use the table above.

A folder that is there and still unreadable by the app is the next section. Whether you can open it in Finder does not settle it, because the helper that reads it runs under the app's permissions.

Git LFS is required but not installed

Anthropic's second cause, and the only one of the three that comes with a message of its own:

Git LFS is required by this repository but is not installed

Anthropic puts it as if you see this line, so it is a message to match rather than a state to diagnose.

How to fix it

1. Install Git LFS from git-lfs.com, or through your package manager.
2. Run git lfs install once, which wires it into your Git configuration.
3. Restart the app and open the session again.

A session that runs in its own worktree needs Git as well, and Anthropic's page carries a separate message for that case.

macOS permissions

Anthropic's third cause, file permissions, comes without any hint of which permissions it means. Two macOS reports fill that in: the directories macOS protects, and the ones a cloud provider mounts.

On #32584, filed March 9, 2026, every project inside ~/Documents failing at once, while projects on ~/Desktop and in ~/Projects worked. They had granted Full Disk Access to the app, to that helper and to every Claude binary, and ran two different privacy resets, tccutil reset SystemPolicyAllFiles com.anthropic.claudefordesktop and tccutil reset SystemPolicyDocumentsFolder com.anthropic.claudefordesktop. Nothing changed. The line they quote is a helper program failing:

[error] [LocalSessionManager] Failed to check git status: Failed to spawn git (via disclaimer): /Applications/Claude.app/Contents/Helpers/disclaimer exited with code 128: fatal: Unable to read current working directory: Operation not permitted

Six days later, #34554 found the same helper failing on ~/Library/CloudStorage, where OneDrive and iCloud Drive appear on macOS, with the process exiting code 1. Their log also carries the line unhealthy cycle (0s, hadFirstResponse=false, reason=no_response).

Those two commands carry a bundle id for a reason, so copy them whole if you run them: without com.anthropic.claudefordesktop on the end, tccutil reset clears the permission for every app on the Mac, not just this one.

The same reporter went further on #26981 on March 16, 2026, the issue #32584 was later closed as a duplicate of. They wrote that this is not a macOS permission or sandbox issue: the app carries no sandbox entitlement, the bundled CLI reads those paths fine, and they called it a session-start regression that began at 2.1.74. #32584, the report above, failed on 2.1.64 two weeks earlier, so if this is one regression it did not begin at 2.1.74, and if there are two, nobody has separated them. That is one reporter's diagnosis of their own timeline, and nobody has confirmed it.

How to fix it

1. Move the project to a folder macOS does not protect, such as ~/Projects. #32584 reports that this works.
2. If the folder has to stay, leave a symlink in the original place pointing at the new location. Note that moving a project out of ~/Library/CloudStorage also stops it syncing there.
3. Full Disk Access is worth trying and costs little, though the reporter who tested it hardest ended up saying permissions were not the cause at all.

Sources: #32584 by jsmith3465, #34554 and #26981's March 16 comment, both by stroudcollectivus.

Windows: the MSIX install

#34382, filed on March 14, 2026, is an MSIX install of the app on Windows 11 that hit the message on every attempt:

[error] Session local_xxx query error: Claude Code process exited with code 3221225781

That number is the decimal form of 0xC0000135, Windows's code for a program that cannot start because a library it needs is missing. Their own diagnosis is a path mismatch: the app looks for the binary at C:\Users\<user>\AppData\Roaming\Claude\claude-code\<version>\claude.exe, while MSIX filesystem virtualisation actually puts it under \AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\<version>\claude.exe. They add that %APPDATA%\Claude does not exist on their machine at all, that the binary ran when they launched it by hand, and that installing the Visual C++ Redistributable did not resolve it. No fix is published.

What to try

1. Nothing here is a repair, so the honest first step is to run the same session from the command line instead.
2. The Visual C++ Redistributable is worth installing if your machine has never had it, though this reporter already had it and it changed nothing.
3. Reinstalling from Anthropic's download gives you the same MSIX package #34382 used, so do not expect it to change this.

Source: #34382 by hell3nder.

Windows: a silent stop with no exit code

Filed the same day, #34274 ran Windows 11 without the Visual C++ Redistributable. They could type a prompt and submit it, after which the session stopped silently and the tab showed the message. They filed it as the redistributable being missing and attached their log bundle.

That report quotes no exit code, and nobody has confirmed the diagnosis, so read it as one user's report, not as the cause. It is the row to start on when your session stops without printing anything.

What to try

1. Install the Microsoft Visual C++ Redistributable and start the session again. It is cheap, and on a machine that has never had it, this is the only report in the set that points at it.
2. If it changes nothing, open Help, then Troubleshooting, then Show Logs in File Explorer, and look for an exit code to match the row above.

Source: #34274 by Knutsi.

Windows on ARM

#28184, filed on February 24, 2026, came from a Surface Laptop 7, and the same account and app version on an x86 machine did not have the problem. Their sessions crashed after a few moments of work, every time. main.log shows exit code 3, and a second file, cowork_vm_node.log, repeats one line hundreds of times:

VM not supported (win32/arm64), skipping

Their reading is that the internal virtual machine has no build for Windows on ARM. One other commenter named their hardware, a Qualcomm ARMv8 machine, and three more said only that they saw the same failure. Clearing the app's cache folders did not help, and the report was closed with no fix.

What to try

1. Check that you are on Anthropic's ARM64 build and not the x64 one, which its desktop page offers separately. That is a basic check, not a fix, and the log above suggests the reporter was already on ARM.
2. Use Claude Code in a terminal on the same machine. That is a way to keep working, not a repair, and the report did not test it.

Source: #28184 by siskokid86.

A crash loop after compaction

#30117, filed on March 2, 2026, describes a long session that ran out of context and compact into a new conversation. On the next launch the app retried a hook against the now-dead session and crashed, every time, four times running. The log line they pasted is in a comment on #28405, and it is the shape to search for:

Session local_xxx query error: CLI output was not valid JSON. This may indicate an error during startup.
Output: {"type":"control_request","request_id":"…","request":{"subtype":"hook_callback","callback_id":"hook_2",…

They closed their own report as a duplicate of #28405. That thread is where the whole failure was worked out, and its trigger is broader than compaction: one reporter found that reading any file containing U+2028 or U+2029 killed the session, because both characters are line terminators to JavaScript and break the JSON the app passes between the CLI and the desktop app. Both characters turn up in text converted from a .docx.

An Anthropic collaborator replied on #28405 on March 7, 2026 that a fix would go out with the next release.

What to try

1. Update the app, then start a new session rather than reopening the compacted one.
2. If you cannot update, avoid asking a session to read a file that may contain U+2028 or U+2029, and start a fresh session to get working again.

Sources: #30117 by razielpanic, and #28405 by Ajon-Cisneros with its March 7 collaborator reply.

Two command-line messages people confuse with this one

Both are in Anthropic's error reference under Command-line errors, and neither is the desktop message.

Failed to resume the conversation

Failed to resume the conversation.
Run claude --resume <session-id> to retry, or claude to start a new session.

Claude Code could not read the saved transcript you picked, so it ended the process instead of continuing with half of it. Run the retry command the message prints. If that fails on a version before 2.1.285, run claude update and resume again: those versions fail on a transcript holding an entry they cannot read.

No conversation found with session ID

No conversation found with session ID: <session-id>

The ID you passed to claude --resume matched no saved transcript. Claude Code looks in the current project first, then in every other project on the machine; before 2.1.223 it stopped at the current project and its worktrees. Open the picker with claude --resume and press Ctrl+A to widen it to every project.

Anthropic lists four causes: a mistyped ID, a transcript past the retention window, which is 30 days by default, a session that ran on another machine, and two copies of a project directory under ~/.claude/projects carrying one ID. Sessions made with claude -p or the Agent SDK never appear in it.

Source: Anthropic, Claude Code error reference.

The "Failed to load project" wording

The report behind #30746, filed on March 4, 2026, is titled "Failed to load session" on Claude Code in macOS desktop app, and the log it quotes says that too. One sentence in its body says Failed to load project instead, so that wording looks like a slip in the report, not a second message. The reporter found no cause, and neither did we. They did post a workaround the next day, on March 5, 2026: connecting the project to GitHub and working through a paired cloud environment seemed to get them going, at the cost of not being able to work locally.

Three things people try, none of which is an action Anthropic gives for this message: reinstalling, which #32584 tried in full and reported as no change; granting Full Disk Access and stopping there, which did not help either; and treating the command line as a repair, when it is a way to keep working.

Source: #30746 by rogierguitar.

Several sessions, and one that stops

28 issues are titled with this message as of October 25, 2026: 15 closed as not planned, 7 as duplicates and 6 as completed. 13 of them, #34382 among them, were closed by the inactivity bot, not by a fix, so a closure is not a verdict.

If you run many sessions, a stopped one should look stopped. Omniscio, the desktop app we make for running Claude Code sessions, shows each session's state at a glance. It starts those sessions itself rather than through the app's Code tab, so this screen is not one its users see. The features page lists the rest, and the download page has the installers.

Where to go next

Claude Code error messages explained is the index for everything Claude Code itself prints. Claude Code on Windows covers the Windows install, and How to run multiple Claude Code sessions at once covers the worktree setup.

Sources

Every message, meaning and step here rests on one of these, read 2026-10-25.

• Anthropic, Claude Desktop application: the message, its three causes and its two actions, the Git LFS wording, the Help > Troubleshooting log route, the Console.app and Event Viewer steps, and the Windows ARM64 installer. It is the only page in Anthropic's documentation that mentions the message.
• Anthropic, Claude Code error reference: the two command-line messages, the Ctrl+A step, the 30-day retention and the duplicate-copies cause.
• #34382 (hell3nder) for the MSIX exit code, the path-mismatch diagnosis and the redistributable not resolving it; #34274 (Knutsi) for the silent stop with no exit code.
• #32584 (jsmith3465) for the ~/Documents failure, the disclaimer helper and exit code 128, and the full uninstall that changed nothing; #34554 (stroudcollectivus) for cloud storage and exit code 1.
• #26981 (lherman0), for the March 16, 2026 comment by #34554's reporter calling it a 2.1.74 session-start regression rather than a permissions issue.
• #28405 (Ajon-Cisneros) for the hook_callback crash, the U+2028/U+2029 trigger and the March 7, 2026 collaborator reply; #30117 (razielpanic) for the compaction path into it.
• #30746 (rogierguitar) for the wording, which has no known cause; #28184 (siskokid86) for Windows on ARM, exit code 3 and the %APPDATA%\Claude\logs\ folder.

Common questions

Is "Failed to load session" the same as "No conversation found with session ID"?

No. The first is a desktop app message from the Code tab. The second is a command-line message from claude --resume, and Anthropic gives it its own section in the error reference.

What does Anthropic say to do about it?

Its desktop troubleshooting page gives three causes: the selected folder may no longer exist, a Git repository may require Git LFS that is not installed, or file permissions may prevent access. The actions it gives are to select a different folder, or to restart the app.

Does giving the app Full Disk Access fix it?

One reporter granted it to the app, the helper and every Claude binary and reset two different privacy permissions; nothing changed. The reporter behind #34554 then wrote on #26981 that it is not a macOS permission or sandbox issue at all.

Is there a fix for Windows on ARM?

No fix is published. #28184 was closed for inactivity, and Anthropic's desktop page lists a separate Windows ARM64 installer, so check which build you installed. Claude Code in a terminal is a way to keep working, and the report did not test it.