[BUG] Claude Desktop (Windows, MSIX) fails every launch — "untrusted mount point" (STATUS_REDIRECTION_NOT_TRUSTED); Squirrel/winget build works on same machine

Open 💬 1 comment Opened Jun 12, 2026 by anijatsu

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 (Windows) bug, not the CLI — filing here as this repo is where desktop issues are triaged.

The MSIX desktop build (ClaudeSetup.exe from claude.com/download, package Claude_1.12603.1.0_x64__pzs8sxrjxfjjc) fails on every launch with:

C:\Program Files\WindowsApps\Claude_1.12603.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe — The path cannot be traversed because it contains an untrusted mount point.

This is NTSTATUS 0xC00004BE (STATUS_REDIRECTION_NOT_TRUSTED), the ntfs.sys redirection-trust mitigation. The winget/Squirrel build (Anthropic.Claude, installs to %LOCALAPPDATA%\AnthropicClaude) runs perfectly on the identical machine — but has no Cowork, so this blocks Cowork entirely.

Process Monitor (full boot→failure capture) shows claude.exe's entire footprint at launch is two events, identical across two launch attempts:

  1. Load_Image C:\...\app\claude.exe → SUCCESS
  2. RegQueryValue HKLM\System\CurrentControlSet\Services\bam\State\UserSettings\<SID>\Claude_pzs8sxrjxfjjc → NAME_NOT_FOUND

…then the process exits. No file I/O returns the mount-point status — the binary loads, then raises STATUS_REDIRECTION_NOT_TRUSTED from user-mode startup code (an internal path/redirection-trust check) before issuing any traceable filesystem op. cowork-svc.exe from the same package dir runs fine throughout (writes logs, loads image, all SUCCESS).

cdb -plmPackage Claude_1.12603.1.0_x64__pzs8sxrjxfjjc -plmApp Claude fails earlier at PLM activation with 0x80070002 (FILE_NOT_FOUND) — same path-resolution failure family, before claude.exe's own startup.

Key contrast: cowork-svc.exe (works) vs claude.exe (fails) from the same package directory points to claude.exe's process getting a token/trust level that trips the redirection-trust check during startup path canonicalization, where cowork-svc's does not.

What Should Happen?

The MSIX desktop app launches normally and Cowork is available.

Error Messages/Logs

The path cannot be traversed because it contains an untrusted mount point.
NTSTATUS 0xC00004BE (STATUS_REDIRECTION_NOT_TRUSTED)

PLM activation under cdb: Error 2147942658 (0x80070002, FILE_NOT_FOUND)

Steps to Reproduce

  1. Install winget Anthropic.Claude (works, no Cowork)
  2. In-app, click "Cowork requires a newer installation → Reinstall" (downloads/installs the MSIX)
  3. Launch Claude → "untrusted mount point" error, every time

Ruled out (verified):

  • No reparse points on package dir, app\, C:\Program Files, C:\Program Files\WindowsApps, %LOCALAPPDATA%, %USERPROFILE%, or %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\* (all fsutil reparsepoint query → "not a reparse point")
  • No stale/offline AppX volumes (Get-AppxVolume shows only C: system)
  • No %LOCALAPPDATA%\AnthropicClaude symlink present — MSIX fails even with it absent
  • No redirection-trust enforcement: Get-ProcessMitigation -System / -Name claude.exe show nothing; no IFEO entry; no EnableRedirectionTrustPolicy
  • Signature/cert valid; package staging succeeds (svchost reads all files, all SUCCESS)

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A — Claude Desktop MSIX 1.12603.1.0 (not the CLI)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Secondary issues:

  1. The in-app "Cowork requires a newer installation → Reinstall" button downloads the MSIX, which reinstalls on top of a working Squirrel install and re-breaks launch — a regression loop with no escape for affected users.
  2. The MSIX converts %LOCALAPPDATA%\AnthropicClaude into a symlink into its package store; uninstalling the MSIX deletes that whole path, taking any prior Squirrel install with it.

Environment: Windows 11 Pro 24H2; system drive C: NTFS; machine also has a Dev Drive (ReFS) — redirection-trust interacts with Dev Drive / cross-filesystem trust labeling, flagging as a possible distinguishing factor vs vanilla setups.

Happy to run a symbolicated/debug build or provide the full ProcMon .PML capture privately.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗