[BUG] Failed to resume session: EINVAL: invalid argument, stat 'C:\Users\username

we are experiecing a same issue on win11 devices.

User2:
Failed to resume session: EINVAL: invalid argument, stat 'C:\Users\[USERNAME]\AppData\Roaming\Claude\local-agent-mode-sessions\[SESSION-ID]\aeb8ff93-4a21-4cdb-8882-57f71917aa81\local_7cbd5c29-88c8-4bf6-9a15-b675119f8fd2\.claude\projects\C--Users-[USERNAME]-AppData-Roaming-Claude-local-agent-mode-sessions-[SESSION-ID]-aeb8ff93-4a21-4cdb-8882-57f71917aa81-local-7cbd5c29-88c8-4bf6-9a15-b675119f8fd2-outputs\62dc2fef-34b8-4c88-96fe-0765b3c468af.jsonl'

user2:
Failed to resume session: EINVAL: invalid argument, stat 'C:\Users\[USERNAME]\AppData\Roaming\Claude\local-agent-mode-sessions\[SESSION-ID]\aeb8ff93-4a21-4cdb-8882-57f71917aa81\local_5c701bb9-8e1c-41a2-9e32-384856cb5bb3\.claude\projects\C--Users-[USERNAME]-AppData-Roaming-Claude-local-agent-mode-sessions-[SESSION-ID]-aeb8ff93-4a21-4cdb-8882-57f71917aa81-local-5c701bb9-8e1c-41a2-9e32-384856cb5bb3-outputs\[OUTPUT-FILE].jsonl'

Here's what Claude generated for me to expound on the same issue:

Root Cause

The project hash directory under .claude/projects/ is derived from the session's own working directory path (with separators replaced by dashes). Since the working directory is already inside local-agent-mode-sessions, the path embeds itself:

local-agent-mode-sessions\{session}\{space}\{local}\
  .claude\projects\
    C--...-local-agent-mode-sessions-{session}-{space}-{local}-outputs\
      {file}.jsonl

Impact

• Cowork is completely non-functional after the first exchange in any session
• The error is not dismissable or recoverable — it blocks all continued use
• 100% reproduction rate — every session, every time
• Regular Chat mode works fine; only Cowork is affected

Steps to Reproduce

1. Open Claude Desktop on Windows 11
2. Switch to Cowork mode
3. Send any message and let Cowork respond
4. Send a follow-up message
5. Error appears: Failed to resume session: EINVAL: invalid argument, stat '...'

Remediation Attempted (All Failed)

| # | What I tried | Result |
|---|---|---|
| 1 | Enabled Windows long path support — LongPathsEnabled = 1 in registry, rebooted | No change |
| 2 | Cleared local-agent-mode-sessions folder | Folder immediately recreated on launch with same session UUID. IDs are server-side. |
| 3 | Deleted VM folders (vm_bundles and claude-code-vm) | No change. Recreated on launch. |
| 4 | Complete uninstall + delete all app data + reinstall | Same error on clean install. Same session UUID returns. |
| 5 | Created NTFS junction to shorten real path | Project hash shortened (confirmed junction is resolved), but overall path still too long. |
| 6 | Added longPathAware manifest to claude-code\2.1.128\claude.exe | No effect — the stat call likely happens inside the VM sandbox. |
| 7 | Verified OS long path support — successfully created and accessed a 382-char path without \\? prefix | Long paths work fine on this system. The EINVAL is NOT a Windows OS limitation. |

Key Finding: This Is NOT a Windows Path Length Issue

Windows long paths are fully functional on this system — I successfully created and accessed a 382-character path without the \\? prefix. The EINVAL error originates inside the Cowork VM's sandboxed Node.js process, which doesn't inherit the host's long-path registry setting or manifest configuration. A longPathAware manifest placed next to claude-code\2.1.128\claude.exe had no effect, confirming the failing fs.stat call is inside the VM.

Multiple Error Instances

Each Cowork attempt creates a new local session UUID but the same outer session/space IDs persist across complete uninstall + data deletion + reinstall, confirming they are stored server-side. Five different local session UUIDs were generated across attempts — all fail identically with the same self-referencing path structure.

Environment

• OS: Windows 11, AMD64
• App: Claude Desktop v1.5354.0.0 (MSIX package)
• Claude Code: 2.1.128
• Node.js (host): v25.9.0
• Registry: LongPathsEnabled = 1
• Session storage: Still using local-agent-mode-sessions (no claude-code-sessions directory exists)
• Note: The MSIX/UWP sandbox redirects %APPDATA%\Claude\ to %LOCALAPPDATA%\Packages\Claude_<ID>\LocalCache\Roaming\Claude\, adding ~70 characters to every real path before the app's directories even begin.

Suggested Fix

The .claude/projects/ directory name should not be derived from the full working directory path when that directory is inside local-agent-mode-sessions. Options:

1. Use a short hash (SHA-256 truncated to 12 chars) instead of the full dash-separated path
2. Detect when the working directory is a session directory and use a fixed short name
3. Ensure the VM's Node.js process is long-path-aware (manifest + registry)
4. Cap the project directory name to a safe length

Update to finding above:
Update: Root Cause Identified — UWP Filesystem Virtualization
After extensive side-by-side comparison with a colleague whose Cowork works perfectly, we've identified the root cause.
The Difference
Working machine (colleague):

App data writes directly to %APPDATA%\Claude\
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude does NOT exist
Session project hash path: 402 characters — works fine

Broken machine (mine):

App data is redirected by UWP filesystem virtualization to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
The app thinks it's writing to %APPDATA%\Claude\ but Windows silently redirects
Session project hash path: 439 characters at the virtual level, 500+ at the real sandbox path — EINVAL on every resume

Both machines run the identical MSIX package (v1.7196.0.0), same claude-code (2.1.138), same SignatureKind (Developer), same Windows 10 Pro Build 26200. The colleague does not have Node.js installed; I do, but removing it from PATH had no effect.
Why Some Machines Get Sandboxed and Others Don't
We were unable to determine exactly what triggers UWP filesystem virtualization for this package. We checked:

AllowAllTrustedApps registry key — changed from 0 to 1, no effect on sandboxing behavior
Get-AppxPackage properties — identical on both machines
MDM/Appx policies — identical on both machines
Windows edition and build — identical (Windows 10 Pro 26200)

The sandbox redirect appears to be baked into the package registration on affected machines and cannot be changed through registry settings.
Why the Path Length Matters
The colleague's 402-character path works because fs.stat receives the real path. On my machine, fs.stat receives the virtual %APPDATA%\Claude\... path (439 chars), but the OS resolves it through the UWP virtualization layer to the much longer sandbox path. Even though Windows long paths are enabled and verified working (tested 382-char file creation successfully), the sandbox translation layer appears to not support them.
Additional Attempts (All Failed)

Created NTFS junction from sandbox path to %APPDATA%\Claude — app refuses to launch ("Claude Desktop failed to launch")
Created NTFS junction on local-agent-mode-sessions to C:\CL — project hash shortened but overall path still too long
Added longPathAware manifest to claude-code\2.1.138\claude.exe — no effect (stat happens inside VM)
Removed Node.js from PATH — no effect (app uses bundled runtime)
Changed AllowAllTrustedApps from 0 to 1 — no effect on sandbox behavior

Suggested Fix
The app needs to handle long paths inside the VM regardless of sandbox status. Options:

Use a short hash for the project directory name instead of the full dash-separated path
Enable long path support in the VM's Node.js process via manifest or --enable-long-paths flag
Detect UWP sandbox and adjust path construction accordingly
Don't embed the working directory path in .claude/projects/ when the working directory is inside local-agent-mode-sessions

This affects any Windows machine where UWP filesystem virtualization is active for the Claude MSIX package. The trigger for virtualization is unclear but appears to be non-deterministic or based on machine-level state that predates the Claude installation.

@eyobzeleke @vipatel12 This following worked for me to resolve this issue.

Fix: Claude Desktop Cowork "Failed to Resume Session" Error on Windows

Problem

Claude Desktop's Cowork feature fails after the first interaction in every session with the error:

Failed to resume session: EINVAL: invalid argument, stat 'C:\Users\...\local-agent-mode-sessions\...'

This is caused by UWP filesystem virtualization redirecting the app's data to a deeply sandboxed path, which combined with Cowork's internal directory structure exceeds Windows filesystem limits.

Who Is Affected

Windows machines where ALL of the following are true:

• Claude Desktop is installed (MSIX package)
• The UWP sandbox folder exists at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\
• App data is being written to the sandbox path instead of %APPDATA%\Claude\

This commonly occurs when Node.js or the Claude Code CLI was installed before the Claude Desktop app, or when the registry key AllowAllTrustedApps was set to 0.

How to Check If You're Affected

Open PowerShell and run:

Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions"

If this returns True, your app is using the sandboxed path and you may be affected.

Then confirm with:

Test-Path "$env:APPDATA\Claude\local-agent-mode-sessions"

If this returns False, your app data is going to the sandbox instead of the correct location.

A healthy setup should show the opposite: False for the sandbox path and True for %APPDATA%\Claude\local-agent-mode-sessions.

---

Fix (Requires Admin Rights for Step 1)

Step 1: Update the Registry (requires admin)

Open PowerShell as Administrator and run:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name "AllowAllTrustedApps" -Value 1

If the key doesn't exist yet, create it:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name "AllowAllTrustedApps" -Value 1 -PropertyType DWORD -Force

Reboot the machine.

Step 2: Close Claude Desktop

After rebooting, if Claude Desktop auto-launched, close it completely (check the system tray for the Claude icon, right-click, and quit).

Verify it's closed:

Get-Process -Name "claude" -ErrorAction SilentlyContinue

This should return nothing.

Step 3: Delete the Old Sandbox Data

Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude" -ErrorAction SilentlyContinue

Note: This deletes the desktop app's cached data only. It does NOT affect:

• Your conversations (stored server-side on your account)
• Your Claude Code CLI data (stored in %USERPROFILE%\.claude\)
• Your account settings or subscription

You will need to sign back into the desktop app after this step.

Step 4: Relaunch Claude Desktop

Open Claude Desktop from the Start menu and sign in.

Step 5: Verify the Fix

Open PowerShell and run:

Test-Path "$env:APPDATA\Claude\local-agent-mode-sessions"

This should return True.

Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions"

This should return False.

If both results match the expected values above, the fix is working. Test Cowork by sending a message, navigating away from the conversation, and then returning to send a follow-up message. The "Failed to resume session" error should no longer appear.

---

What This Fix Does

Claude Desktop is distributed as an MSIX package. On some Windows machines, the app's file writes to %APPDATA%\Claude\ are silently redirected by Windows to a deeply nested sandbox path:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\

This adds ~70 characters to every file path. Cowork creates session directories with long names that include multiple UUIDs and a project hash derived from the full directory path. When the sandbox overhead is added, the resulting paths exceed Windows filesystem limits, causing the EINVAL error on every session resume.

Setting AllowAllTrustedApps = 1 allows developer-signed MSIX packages (like Claude Desktop) to write directly to standard filesystem locations. Deleting the old sandbox data ensures the app starts fresh at the correct path.

Risk Assessment

• This is a standard Windows setting for MSIX app deployment
• It does not disable any security features for Microsoft Store apps
• It only affects sideloaded/developer-signed packages
• The change can be reverted by setting AllowAllTrustedApps back to 0

I attempted a clean reinstall using the official Claude Setup.exe. After removing the Appx package and deleting the package data folder, reinstalling still places Claude at:

C:\Program Files\WindowsApps\Claude_1.8555.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe

So the public installer appears to reinstall the MSIX/WindowsApps packaged version. I do not appear to have a way to install a traditional non-MSIX desktop version.

So, I've now tried all options above and I still can't get it to work without getting error message... it works for awhile and then gives error.

<img width="1503" height="1120" alt="Image" src="https://github.com/user-attachments/assets/72ffe48b-e1c2-4d3a-8d39-2b5a70c6d173" />

Hi all, we think we have a breakthrough on this. The core cause appears to be our security platform, Xcitium (formerly Comodo).
We'd removed Xcitium while debugging an unrelated issue on a colleague's machine and noticed "by accident" that the error in this thread stopped. I then removed it from my own machine and the problem went away completely — so the endpoint security is the cause.

For context, Xcitium runs unknown or unrecognized programs inside an isolated "Containment" sandbox. It appears to be sandboxing the Claude Code process and blocking it from reading its own session files. Rather than leave the software off, the fix should be an exclusion:

Whitelist the Node.js process used by Claude Code (node.exe / the claude process)
Exclude the folder C:\Users\[username]\.claude

We are working with Xcitium to get their feedback on this as well. But this maybe it!

---------------------------------------------------------------------------------------------------------------

More explanation of how Xcitium was affecting Claude Cowork:

Xcitium uses a "default-deny" containment model: any executable it doesn't already recognize as trusted is automatically run inside an isolated virtual sandbox rather than directly on the real system. Inside that sandbox, the program's file and registry operations are redirected to a virtualized shadow copy instead of the real filesystem — the program thinks it's reading and writing normally, but it's actually operating on a separate, isolated layer.
Claude Code stores its session state as files under the .claude folder in the user profile. Because the Node.js process running Claude Code isn't on Xcitium's trusted list, it gets placed in containment, and its access to those session files goes through the virtualization layer. When Claude Code tries to stat (read the metadata of) a session file, the sandboxed/redirected path doesn't satisfy the system call cleanly, and Node surfaces it as the EINVAL: invalid argument, stat error seen in this thread. The session files themselves aren't corrupted — the security layer is intercepting and breaking the read.
This also explains why fully removing Xcitium fixes it: with no containment in place, the process reads its real session files directly and everything works.