[BUG] Windows MSIX: shipped .msix is not streaming-ordered (AppxManifest.xml at 99.6% of the archive) — every URI-based auto-update fails with 0x87E80034

Status Open

Maintainer reply None cached

Activity 0 comments · opened Oct 13, 2026

What's Wrong?

The Windows .msix is not laid out for streaming installation, so the desktop app's URI-based auto-update can never succeed. It fails every time with:

[updater] Found an update, downloading
[error] [updater] Auto-update error: MsixvcStagingSession::GetManifestReader ... 0x87E80034

Root cause: the Appx metadata sits at the end of the archive. Parsing the central directory of the current release (2.31226.1, 294,300,862 bytes, 3987 entries, ZIP64):

| entry | offset | position |
|---|---|---|
| app/chrome_100_percent.pak | 0 | first entry in the archive |
| app/chrome_200_percent.pak | 694,698 | |
| app/v8_context_snapshot.bin | 1,915,775 | |
| … | | |
| AppxManifest.xml | 293,144,515 | 99.61% |
| AppxBlockMap.xml | 293,147,357 | 99.61% |
| [Content_Types].xml | 293,783,008 | 99.82% |
| AppxSignature.p7x | 293,783,517 | 99.82% |

A streaming (URI-based) install reads the manifest and block map from the front of the stream — that is what the staging session is for. Here the first 64 KiB contain nothing but chrome_100_percent.pak, so GetManifestReader has nothing to parse and fails with 0x87E80034. A file-based install has random access, reads the central directory at the end, finds everything, and succeeds — which is why double-clicking the same .msix always works.

This is not an environment problem. On the same machine the streaming path is healthy for other packages:

Add-AppxPackage -Path 'https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx'
# fails only with 0x80073D06 "a higher version is already installed"

It downloaded, parsed the manifest, and rejected the install on version — so Delivery Optimization and the staging session work. Claude's package is the only one that fails: 87 consecutive 0x87E80034 failures in AppXDeploymentServer/Operational over one week, zero successes, across five different releases. The bytes are fine as well — MD5 of the download matches the x-goog-hash response header, and Get-AuthenticodeSignature returns Valid (Anthropic, PBC → DigiCert).

Likely origin. The archive contains a [Content_Types].old entry next to [Content_Types].xml, which suggests the package is post-processed by a plain zip tool after makeappx produced it. That rewrite is what moves payload to the front and metadata to the back; makeappx pack on its own emits a streaming-ordered package.

Related: #97366 reports the same failure with excellent Delivery Optimization traces (the 0x8007000D on the first 64 KiB is the same symptom — the data is not corrupt, it is just not what the consumer expects at that offset), but stops at the guess that the streaming path "rejects this package" without identifying why.

What Should Happen?

Background auto-update should install the new version, as installing the same .msix from a local file does.

Two ways to fix it:

Repack so the metadata leads — [Content_Types].xml, AppxBlockMap.xml, AppxManifest.xml, AppxSignature.p7x before any payload file. This restores auto-update for every MSIX user and needs no client change.
Or have the updater download to a local file and call AddPackage on the local path. This works today, but only hides the packaging problem.

Error Messages/Logs

main.log:
  [updater] Found an update, downloading
  [updater] Auto-update error: MsixvcStagingSession::GetManifestReader ... 0x87E80034

AppXDeploymentServer/Operational:
  603  Started deployment Add operation (NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse)
  402  error 0x87E80034: reading manifest from Claude-<hash>.msix failed: Unknown error

Package layout (central directory, ZIP64 offsets resolved):
  app/chrome_100_percent.pak        offset             0   <- first entry
  AppxManifest.xml                  offset   293,144,515   = 99.61%
  AppxBlockMap.xml                  offset   293,147,357   = 99.61%
  [Content_Types].xml               offset   293,783,008   = 99.82%
  AppxSignature.p7x                 offset   293,783,517   = 99.82%

Steps to Reproduce

Run Claude Desktop for Windows (MSIX) and wait for a release newer than the installed one.
Every update check logs Found an update, downloading and fails with 0x87E80034 a few seconds later. It never succeeds.
Download the same .msix and install it from the local file — this succeeds every time.
To see the cause directly, read the package's central directory and look at the offsets of AppxManifest.xml and AppxBlockMap.xml.

Additional notes for anyone hitting this

-DeferRegistrationWhenPackagesAreInUse stages the package without closing the app, but restarting the app does not apply it — the deferred registration needs a sign-out. Registering explicitly works:

Add-AppxPackage -Register "C:\Program Files\WindowsApps\Claude_<version>_x64__<pfn>\AppxManifest.xml" `
  -DisableDevelopmentMode -ForceTargetApplicationShutdown

-ForceTargetApplicationShutdown is required: without it the registration loses a race against the still-active AUMID and fails with 0x80073D02 (deployment aborted due to active service Claude_...!Claude), even after every process from the package folder has been killed.

Claude Code Version

Claude Desktop for Windows 2.19675.0.0 → 2.31226.1 (MSIX, sideloaded; GetAppInstallerInfo() returns NULL, so there is no AppInstaller update source and the app updates itself). This is the desktop app's updater, not the CLI.

Platform

Anthropic API

Operating System

Windows 11 Pro 26300.9457

View original on GitHub ↗