### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? ## Summary After the idle stealth update to **Claude 2.16120.0.0** (MSIX), the desktop app fails to launch with "The parameter is incorrect" (0x80070057).

[BUG] Windows MSIX 2.16120: app won't launch (0x80070057 "The parameter is incorrect") when %LOCALAPPDATA%\Google is a junction to another volume

Status Fixed / completed

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 5 comments · opened Sep 30, 2026 · closed Sep 30, 2026

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?

Summary

After the idle stealth update to Claude 2.16120.0.0 (MSIX), the desktop app fails to launch with
"The parameter is incorrect" (0x80070057). Root cause: the manifest's
FileSystemWriteVirtualization excluded directory $(KnownFolder:LocalAppData)\Google\Chrome\User Data
resolves through a directory junction (%LOCALAPPDATA%\Google → M:\_appdata\Local\Google,
M: is a local fixed NTFS volume). Windows then fails to create the Desktop AppX container.
The previous version (installed before the stealth update on 2026-09-30) launched fine with the same junction,
which has existed for years.

Environment

Windows 11 Enterprise 22H2, build 22621.6060 (manifest MaxVersionTested = 10.0.22621.0)
Claude_2.16120.0.0_x64__pzs8sxrjxfjjc, package Status: Ok, single version installed
%LOCALAPPDATA%\Google is a junction to M:\_appdata\Local\Google (M: = local fixed NTFS volume, not subst/network)

Symptoms

Dialog: C:\Program Files\WindowsApps\Claude_2.16120.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe — The parameter is incorrect.
No new lines in any Claude log (the process never starts).
Event log Microsoft-Windows-AppModel-Runtime/Admin:
ID 216: 0x80070057: Cannot create the Desktop AppX container for package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc because an error was encountered configuring runtime.
ID 208: 0x80070057: Cannot create the process for package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc because an error was encountered configuring runtime. [LaunchProcess]
Also on every launch attempt (likely unrelated noise): CoworkVMService: failed to configure/disarm SCM recovery actions ... open service: Access is denied.
Other packaged desktop apps (e.g. Windows Terminal) create their containers fine on the same machine.

What did NOT help

Launching via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
Settings → Repair / Reset
Renaming %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium
Full reboot
Remove-AppxPackage + reboot + clean reinstall of 2.16120 (fails on first launch, before any user data is restored)

Confirmation / workaround

Renaming the junction %LOCALAPPDATA%\Google → app launches immediately.
Permanent fix applied: removed the junction, copied Chrome data back to a real folder under %LOCALAPPDATA%\Google.

App and Chrome both work.

Steps to reproduce (expected)

Move %LOCALAPPDATA%\Google to another volume and create a junction:

mklink /J "%LOCALAPPDATA%\Google" "D:\_appdata\Local\Google" (with Chrome\User Data inside).

Install / launch Claude 2.16120 (MSIX).
Launch fails with 0x80070057, AppModel-Runtime events 216/208.

Relevant manifest excerpt (2.16120)

<virtualization:FileSystemWriteVirtualization>
<virtualization:ExcludedDirectories>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Google\Chrome\User Data</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-3p</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-Data</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude\logs</virtualization:ExcludedDirectory>
</virtualization:ExcludedDirectories>
</virtualization:FileSystemWriteVirtualization>

Impact

Moving AppData subfolders to another disk via junctions is a common practice (small system SSD).
A single third-party folder layout makes the whole app unlaunchable, with an error that points nowhere,
and Repair/Reset/reinstall cannot fix it. Took ~1.5 h of diagnostics to find.

Suggestions

Avoid excluding third-party browser folders (Chrome User Data) via manifest virtualization exclusions,

or handle paths that traverse reparse points gracefully.

Detect this failure (AppModel-Runtime 216 + 0x80070057) and show an actionable message.
A non-MSIX fallback installer would give users a recovery path (see #93008).
Note: since some version, logs moved to %LOCALAPPDATA%\Claude\logs while the old

LocalCache\Roaming\Claude\logs silently stopped updating — this misled diagnostics.

#92202, #97135, #89599 (container / stealth-update launch failures, but with 0x80070020 and fixed by reboot/reinstall — this case is not).

What Should Happen?

Claude Desktop should launch normally regardless of how third-party folders (e.g. Chrome's User Data) are laid out on disk.
If a virtualization exclusion path cannot be applied, the app should skip it or show an actionable error
instead of an opaque "The parameter is incorrect" that Repair/Reset/reinstall cannot fix.

Error Messages/Logs

Microsoft-Windows-AppModel-Runtime/Admin:
ID 216: 0x80070057: Cannot create the Desktop AppX container for package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc because an error was encountered configuring runtime.
ID 208: 0x80070057: Cannot create the process for package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc because an error was encountered configuring runtime. [LaunchProcess]

Also on each attempt (noise, see #85540):
CoworkVMService: failed to configure SCM recovery actions ... open service: Access is denied.

No Claude log lines are written — the process never starts.
Other packaged apps (Windows Terminal) create containers fine on the same machine.

Steps to Reproduce

Move %LOCALAPPDATA%\Google to another volume and create a junction:

mklink /J "%LOCALAPPDATA%\Google" "D:\_appdata\Local\Google" (Chrome\User Data inside)

Install or auto-update to Claude Desktop 2.16120.0.0 (MSIX).
Launch Claude -> "The parameter is incorrect", AppModel-Runtime events 216/208 with 0x80070057.
Rename the junction (cmd /c ren "%LOCALAPPDATA%\Google" Google_bak) -> Claude launches immediately.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

previous version before 2026-09-30 stealth update (exact number unknown)

Claude Code Version

Claude Desktop 2.16120.0.0 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Manifest excerpt (2.16120):
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Google\Chrome\User Data</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-3p</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-Data</virtualization:ExcludedDirectory>
<virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude\logs</virtualization:ExcludedDirectory>

Impact: moving AppData subfolders to another disk via junctions is common (small system SSD). One third-party folder layout
makes the app unlaunchable; ~1.5 h of diagnostics to find.

Suggestions:

Don't exclude third-party browser folders via manifest virtualization, or handle reparse points gracefully.
Detect AppModel-Runtime 216 + 0x80070057 and show an actionable message.
Provide a non-MSIX fallback installer (#93008).
Logs silently moved to %LOCALAPPDATA%\Claude\logs; old LocalCache\Roaming\Claude\logs stopped updating — misleading during diagnostics.

Related: #92202, #97135, #89599 (container/stealth-update launch failures, but 0x80070020 and fixed by reboot/reinstall — this one is not).
#85540 — explains the CoworkVMService "Access is denied" events (service DACL); same noise here, not the cause.

View original on GitHub ↗

5 Comments

f3msolar-cloud · 15 days ago

Same error here on Claude Desktop 2.16120.0.0 (MSIX), same day (2026-09-30), same AppModel-Runtime events (216/208) with 0x80070057 "The parameter is incorrect". Repair, Reset, uninstall + clean reinstall, sfc /scannow, DISM /RestoreHealth and reboots did not help. Other packaged apps (Calculator, Notepad) launch normally.

Checking reparse points: on my machine %LOCALAPPDATA%\Google is a regular directory, but %LOCALAPPDATA%\Google\Chrome is a junction to {D:\AppsData\Local\Google\Chrome}. So the path to the manifest's excluded directory "Google\Chrome\User Data" traverses a reparse point one level deeper than in the original report. None of the other excluded directories (Claude-3p, Claude-Data, Claude\logs, Microsoft\Office\16.0\WEF) is a reparse point or sits under one. I did not test by renaming the junction, since I already have a working workaround, so this is consistent with the report rather than independently confirmed.

Workaround: "winget install Anthropic.Claude" installs a non-MSIX build (winget manifest 1.44121.2, Installer Type: exe, downloaded from downloads.claude.ai) that then updated itself to 2.16120.0, the same version number as the failing MSIX. So the same app version launches fine outside MSIX on this machine. This may be relevant to #93008 (no non-MSIX installer).

jaffethalfarotorres · 15 days ago

Same error on Claude Desktop 2.16120.0.0 (MSIX), Windows 11: "The parameter is incorrect", with AppModel-Runtime events 216 and 208 (0x80070057) starting the night of 2026-09-29/30. Repair and Reset did not help. On my machine %LOCALAPPDATA%\Google is a regular directory, and fsutil reparsepoint query says Google\Chrome\User Data is not a reparse point (PowerShell still showed a Target value for that path, and I did not check Google\Chrome itself), so I can't confirm the junction cause here. Removing the MSIX (Get-AppxPackage Claude | Remove-AppxPackage) and running winget install Anthropic.Claude (1.44121.2) fixed it. So the non-MSIX build works on an affected machine, which is relevant to #93008.

jaffethalfarotorres · 15 days ago

Correction to my comment above: I checked Google\Chrome itself and it is a junction (LinkType Junction, Target D:\AppData\GoogleChrome). So my setup matches the cause described in this issue, one level deeper than the original report, same as f3msolar-cloud's finding. Google is a regular directory, and the Chrome profile lives on D:. Installing the standalone build with winget install Anthropic.Claude was enough to get the app running without touching the junction. (Also, my earlier command was Get-AppxPackage with a wildcard around Claude; the markdown ate the asterisks.)

TheWhiteCanvas · 15 days ago

I had the same error caused by a symbolic link for AppData\Google.

nextep-prod · 15 days ago

Same failure here on Claude Desktop 2.16120.0.0 (MSIX), and the cause reported in this issue is confirmed on my machine.

Environment: Windows (Spanish language), package Claude_2.16120.0.0_x64__pzs8sxrjxfjjc, Status Ok, SignatureKind Developer.

Timeline:

Version 2.9939.4.0 launched normally on this machine.
Stealth update to 2.16120.0.0 on 2026-09-29 at 22:28 local time (main.log: "[stealth-update] Triggering stealth update after idle timeout", then "beforeQuitForUpdate handler fired").
Every launch since then fails with the dialog "The parameter is incorrect" (Spanish Windows: "El parametro no es correcto").
AppModel-Runtime/Admin logs Id 216 and Id 208, both 0x80070057, on every attempt (for example 2026-09-30 at 18:17:57 and 18:17:59).
The automatic repair registration (RegisterByPackageFullName) at 18:17:57 did not help.

This is not the 0x80070020 orphaned-container case: the old version's containers were destroyed cleanly (Id 217), there were no leftover processes with the old package identity, and the Helium User.dat / UserClasses.dat files were not locked.

Cause: %LOCALAPPDATA%\Google is a directory junction to D:\Google (a different volume), which I created to save space on C:. The 2.16120 manifest lists these excluded directories: Microsoft\Office\16.0\WEF, Google\Chrome\User Data, Claude-3p, Claude-Data and Claude\logs. Google\Chrome\User Data resolves through the junction.

Confirmation: renaming the junction (Google -> Google_junction_bak) made Claude launch immediately. I then restored the junction to leave the machine in its original state.

Expected: the app should launch regardless of junctions in %LOCALAPPDATA%, or show an actionable error. Moving user data folders to another drive with junctions is a common practice.