[BUG] Claude Desktop main app process never launches — CreateProcess ERROR_INVALID_PARAMETER (87), same packaged-activation defect as #86140 but hitting the primary exe, not just Cowork

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest match: #86140, but that's Cowork/VM-service-only; this report is the main app process itself)
• [x] Single bug report
• [x] Using the latest version of Claude Code / Claude Desktop

What's Wrong?

Surface: Claude Desktop (Windows, MSIX, package Claude_1.34493.0.0_x64__pzs8sxrjxfjjc), not the CLI.

The main Claude.exe process never launches at all — not just Cowork/VM service (as in #86140 and its closed predecessors #38396/#38241/#32186/#27652). Every activation path fails identically:

• Start Menu search → click result
• explorer.exe "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"
• Direct Start-Process on the raw exe path
• Post-install auto-launch performed by the installer itself

All four produce the same result: a Windows shell error dialog titled with the literal exe path, body text "The parameter is incorrect" (localized: パラメーターが間違っています), OK button only. Get-Process/Get-CimInstance confirm zero process is ever created — this is a CreateProcess/ActivateApplication-level failure (ERROR_INVALID_PARAMETER, 87), not an app crash.

What Should Happen?

Claude.exe should launch normally from any of the above activation paths, as it presumably does on unaffected machines.

Steps Already Tried (all failed to change the outcome)

1. Windows Settings → Apps → Claude → Advanced options → Repair — failed ("このアプリを修復できませんでした")
2. Windows Settings → Apps → Claude → Advanced options → Reset — completed, no change
3. Fresh download + reinstall via the official installer (Claude Setup.exe, self-elevating MSIX installer) — completes "successfully" per its own log, no change
4. Enabled Developer Mode (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense = 1, confirmed via registry after toggling in Settings) — no change
5. Remove-AppxPackage (genuine full removal, confirmed package gone from Get-AppxPackage and disk) followed by clean reinstall — no change
6. Investigated AppxMetadata\CodeIntegrity.cat — confirmed missing / AppxMetadata folder empty even after a from-scratch clean install. Microsoft-Windows-CodeIntegrity/Operational logs Status 0xC000003A (catalog unloadable) on every launch attempt.
7. Investigated CoworkVMService's security descriptor (sc.exe sdshow): DACL grants only AU (limited rights, no delete/reconfigure) and the service's own virtual account SID — no ACE for Administrators or SYSTEM at all. Even a fully elevated admin token gets OpenService FAILED 5: Access is denied trying to reconfigure/delete it. This matches the installer's own log line: Removing conflicting CoworkVMService...WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
8. Installer log also repeatedly shows: Windows rejected data-preserving removal for Claude_1.34493.0.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update — this occurs even with Developer Mode confirmed ON, suggesting the installer's own error-message mapping for 0x80073CFA may be inaccurate/stale for this failure mode.
9. Took ownership of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService and granted Administrators FullControl via .NET RegistryKey.SetAccessControl (SetAccessControl reported success, owner confirmed changed) — but sc.exe sdshow continued showing the unmodified original DACL, both before and after a full reboot. The Service Control Manager appears to reassert/ignore the on-disk ACL for this packaged service across restarts.
10. Full machine reboot — no change to the launch failure.

Root Cause (best available evidence)

This matches the failure class described in #86140: AppX packaged-process activation returns ERROR_INVALID_PARAMETER (87) on this Windows build. #86140 documents this for CoworkVMService (SERVICE_PKG_SERVICE) specifically, with a working per-service workaround (register the same binary as an ordinary unpackaged Win32 service). That workaround doesn't apply here because the affected target this time is the package's primary full-trust application entry point itself, not an auxiliary service — there's no equivalent "run it unpackaged" trick available for the main app the way there is for a Win32 service.

Given the identical error code, identical "silent CreateProcess failure with no app-level or WER trace" signature, and the fact that direct-exe launch and shell:AppsFolder launch fail identically (ruling out a shortcut/AUMID-specific cause), this looks like the same underlying OS-level packaged-activation defect, just hitting the app's main executable rather than only its packaged service.

Suggested Fixes

1. If Anthropic can reproduce packaged-process activation failing for the main app exe (not just the service) on affected Windows builds, that's a strong signal the underlying broker defect is broader than #86140 assumed.
2. Consider whether the installer could detect this exact failure signature (zero process created, ERROR_INVALID_PARAMETER, package Status: Ok) post-install and surface a clearer diagnostic / offer an alternative (e.g., an unpackaged/Squirrel-style fallback installer) rather than reporting "Claude Setup completed successfully" when the resulting install cannot actually launch.

Environment

• OS: Windows 11 Enterprise, build 10.0.26100 (fully updated, no pending feature/cumulative updates besides Defender definitions)
• Claude Desktop package: Claude_1.34493.0.0_x64__pzs8sxrjxfjjc (MSIX, current-user install, SignatureKind: Developer / sideload-signed, Authenticode signature valid)
• No third-party AV/EDR beyond Windows Defender
• No AppLocker/WDAC/ASR rules configured (checked and confirmed absent)
• Domain-joined / Intune-managed device

Is this a regression?

Unknown — first time this specific machine has had Claude Desktop installed/reinstalled during this troubleshooting session, so no "last known working version" on this machine to compare against.

Related: #86140