[BUG] [Claude Desktop] Cowork fails to create local agent mode sessions — ENOENT mkdir with pinned parent UUIDs (MSIX install, junction-mounted AppData)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

This is a Claude Desktop bug (not the CLI). Filing here because there's no separate Desktop template and other Desktop bugs have been filed in this repo.

Every time I send a prompt in Cowork, an ENOENT popup appears and the prompt does not run:

ENOENT: no such file or directory, mkdir 'C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\43055aa4-a742-487b-8a3e-96658c49cf20\84cdec91-0a1f-41eb-874e-b8bf684dc125\local_<new-uuid-each-time>'

The first two UUIDs (43055aa4… and 84cdec91…) are identical across every attempt and every app restart. Only the final local_<uuid> changes each time. This suggests those parent UUIDs are persisted somewhere in config, not just on disk — deleting the folder tree does not clear them; Claude Code recreates the same parent structure on next launch and fails at the same spot.

A manual mkdir from cmd.exe at the exact failing path succeeds. So the filesystem accepts the operation; Claude Code's mkdir call specifically fails.

Additionally: after clearing the sessions folder as a troubleshooting step, all previous Cowork projects no longer appear in the project list — appears to be a consequence of that cleanup rather than a separate bug.

What Should Happen?

Typing a prompt into Cowork should start (or resume) a local agent mode session and execute the prompt. Cowork should also show previously created projects.

Error Messages/Logs

Popup dialog text:

ENOENT: no such file or directory, mkdir 'C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\43055aa4-a742-487b-8a3e-96658c49cf20\84cdec91-0a1f-41eb-874e-b8bf684dc125\local_<varies>'

No stack trace visible in the popup. Not sure where Claude Desktop writes its main.log; happy to attach logs if pointed to the right location.

Steps to Reproduce

1. Launch Claude Desktop on Windows (MSIX install, standard user account)
2. Open Cowork
3. Type any prompt and press send
4. ENOENT popup appears; prompt never runs

Diagnostic steps already taken that did NOT fix the issue:

• Killed all Claude and CoworkVMService processes
• Deleted %APPDATA%\Claude\Cache, Code Cache, GPUCache and relaunched
• Enabled Windows LongPathsEnabled=1 in registry and rebooted
• Verified permissions via icacls: Authenticated Users have Modify (OI)(CI) on the parent
• Verified failing path is ~194 characters (well under MAX_PATH 260)
• Verified mkdir from cmd.exe at the exact failing path succeeds
• Deleted the entire 43055aa4-... session tree — Claude Code recreated the same two parent UUIDs on next launch and failed at the same spot with a new final UUID

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

Unknown — same MSIX build (Claude_1.17377.1.0_x64__pzs8sxrjxfjjc) has been installed throughout.

Claude Code Version

N/A — this is a Claude Desktop bug, not CLI. Desktop app version: Claude_1.17377.1.0_x64__pzs8sxrjxfjjc (MSIX package)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Setup context:

• C:\Users\<user>\AppData\Roaming\Claude is a directory junction pointing to D:\Claude, set up via Cowork's move-to-D-drive feature to save space on C:. Junction verified working via fsutil reparsepoint query.
• User account is a standard (non-admin) Windows account. Admin actions require entering a separate administrator password.
• Windows LongPathsEnabled = 1 in HKLM\SYSTEM\CurrentControlSet\Control\FileSystem (verified via reg query).

Diagnostic detail:

• icacls on the failing parent folder shows: BUILTIN\Administrators (F), NT AUTHORITY\SYSTEM (F), NT AUTHORITY\Authenticated Users (M with OI/CI inheritance), BUILTIN\Users (RX). No denied ACEs.
• Manual mkdir from a normal (non-elevated) cmd.exe at the exact failing path succeeds and creates the folder.
• Deleting the entire 43055aa4-... session tree does not clear the pinned UUIDs — Claude Code recreates the same parent structure on next launch.

Possibly related open/closed issues that touch nearby symptoms (Desktop bugs filed in this repo despite CLI focus):

• #51143 (Claude Desktop blank/white screen on Windows — Cowork unusable, no AppData folders created)
• #56763 (Claude Desktop blank screen, MSIX install correlation noted)

Happy to attach main.log or any other diagnostic output if pointed to the right location — I couldn't find where Claude Desktop writes its logs on Windows.