[BUG] Claude Desktop crashes on launch with "Failed to get 'documents' path" when Windows Documents known folder points to a nonexistent path (common post-OneDrive-uninstall)

Preflight

• I have searched existing issues for "Failed to get 'documents'" and the OneDrive/known-folder class — no open report matches.
• This is a single bug report.
• Reproduced on Claude Desktop 1.2773.0.0 (MSIX, Windows 11); regression cause survives the v1.3036 update.

What's Wrong?

Claude Desktop (MSIX) crashes immediately on launch with no user-visible error if the Windows Documents known folder (FOLDERID_Documents) resolves to a nonexistent path. The installer reports success, the MSIX package registers cleanly, but the Electron main process exits during synchronous top-level module evaluation before any UI can render. The only feedback the user gets is the installer's generic "Claude Desktop failed to launch, please check for updates and try again."

This is a hard crash during module init — no fallback, no retry, no diagnostic shown to the user.

Root Cause

Registry entries for FOLDERID_Documents pointing to a nonexistent path:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
  Personal                                     = C:\Users\<user>\OneDrive\Documents   ← does not exist
  {F42EE2D3-909F-4907-8871-4C22FC0BF756}       = C:\Users\<user>\OneDrive\Documents

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  Personal                                     = C:\Users\<user>\OneDrive\Documents

Windows SHGetKnownFolderPath(FOLDERID_Documents) — invoked by Electron's app.getPath('documents') — returns an error when the registered target directory does not exist. Claude Desktop calls this at top-level module load, uncaught. The exception aborts process startup.

Crash Trace

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\launch-failure.err:

Error: Failed to get 'documents' path
{}
Failed to get 'documents' path
Error: Failed to get 'documents' path
    at Object.<anonymous> (app://\.vite\build\index.js:861:75871)
    at Module._compile (node:internal/modules/cjs/loader:1820:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1953:10)
    at Module.load (node:internal/modules/cjs/loader:1540:32)
    at Module._load (node:internal/modules/cjs/loader:1342:12)
    at c._load (node:electron/js2c/node_init:2:18047)
    at wrapModuleLoad (node:internal/modules/cjs/loader:262:19)
    at Module.require (node:internal/modules/cjs/loader:1563:12)
    at Module.h (app://\.vite\build\index.pre.js:5:3369)
    at _require.e.require (app://\.vite\build\index.pre.js:5:2340)
    at require (node:internal/modules/helpers:152:16)
    at Object.<anonymous> (app://\.vite\build\index.pre.js:62:3680)
    ...

Key observations:

• Object.<anonymous> — top-level synchronous call at module load, not inside an async handler or try/catch.
• Happens in index.js before index.pre.js finishes loading — pre-window, pre-UI initialization.
• Empty {} in the error output suggests the error object has no additional context.

Installer Misleadingly Reports Success

%TEMP%\ClaudeSetup.log:

MSIX package installed successfully
MSIX installation succeeded
Launching Claude via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
=== Claude Setup completed successfully ===

The MSIX install genuinely succeeds; Get-AppxPackage shows Ok. The crash only happens when the Electron process starts. The installer's launch step is fire-and-forget explorer.exe shell:AppsFolder\... — it cannot detect that the launched process immediately exited, so it reports success.

How Common Is This?

Any Windows user whose Documents known folder registry entry points to a nonexistent path will hit this. Common scenarios:

• OneDrive uninstalled without reverting folder redirection (my case)
• OneDrive folder sync disabled for Documents after it was previously enabled
• Corporate policy changes redirecting / un-redirecting known folders
• Manual registry edits / cleanup scripts that remove OneDrive paths
• User profile migration where Known Folder targets weren't updated

OneDrive is preinstalled on Windows 10/11. Users who ever enabled Documents sync and later uninstalled OneDrive or disabled that sync are likely to hit this exact state, and the Microsoft.OneDriveSync AppX package (which can persist even after OneDrive uninstall) has a habit of recreating phantom C:\Users\<user>\OneDrive\ scaffolding on login — any app that tries to resolve those ghost paths gets tripped up. This bug class extends to FOLDERID_Pictures, FOLDERID_Music, and FOLDERID_SkyDrive too; Claude specifically falls over on Documents.

Reproduction Steps

1. Windows 11 machine with Claude Desktop installed and working.
2. Modify the Documents known folder registry to point to a nonexistent path:

   Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' -Name 'Personal' -Value 'C:\nonexistent\Documents'
   Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' -Name '{F42EE2D3-909F-4907-8871-4C22FC0BF756}' -Value 'C:\nonexistent\Documents'
   Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders' -Name 'Personal' -Value 'C:\nonexistent\Documents'

3. Launch Claude Desktop — it will exit immediately with no UI.
4. Check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\launch-failure.err — Error: Failed to get 'documents' path.
5. Revert:

   Set-ItemProperty 'HKCU:\...\User Shell Folders' -Name 'Personal' -Value '%USERPROFILE%\Documents'
   Set-ItemProperty 'HKCU:\...\User Shell Folders' -Name '{F42EE2D3-909F-4907-8871-4C22FC0BF756}' -Value '%USERPROFILE%\Documents'
   Set-ItemProperty 'HKCU:\...\Shell Folders' -Name 'Personal' -Value 'C:\Users\<user>\Documents'

Suggested Fix

1. Wrap app.getPath('documents') in a try/catch. Documents is not critical to core startup; if it throws, log and fall back to app.getPath('userData') or app.getPath('home').
2. Defer the resolution out of top-level module scope so a failure can't prevent the app from starting at all. At minimum the app should render a window and surface a meaningful error before dying.
3. Surface the actual error. The installer's "failed to launch, please check for updates" gives no indication of root cause. The app already writes launch-failure.err — on the next launch attempt, read it and show the user a real message.
4. Same resilience should apply to every other app.getPath(<known-folder>) call — this class of bug will recur on Pictures / Music / SkyDrive for users with ghost OneDrive redirections.

Environment

• OS: Windows 11 Home 10.0.26200 (x64)
• Claude Desktop: v1.2773.0.0 (MSIX, x64) — originally reproduced here; confirmed the same registry-state sensitivity remains in 1.3036.0.0.
• Package: Claude_1.2773.0.0_x64__pzs8sxrjxfjjc
• User scenario: OneDrive uninstalled long ago; Microsoft.OneDriveSync AppX remained and recreated ghost C:\Users\<user>\OneDrive\ scaffolding on login; known folder redirections were never cleaned up.

Happy to provide additional logs or test fixes.