[BUG] Claude Desktop (Windows MSIX): every auto-update fails with 0x87E80034 (MsixvcStagingSession::GetManifestReader); DO stream write fails with 0x8007000D, while the same .msix installs fine from a local file

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 26, 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?

On Windows 11, Claude Desktop's background auto-update never succeeds. Every hourly attempt fails 3–7 seconds after Found an update, downloading:

[updater] Found an update, downloading
[error] [updater] Auto-update error: [Error: Common::Deployment::MsixvcStagingSession::GetManifestReader in MsixvcStagingSession failed with error 0x87E80034. (-2147009296)]

This has happened on every attempt since 2026-09-24, for two consecutive releases (2.7032.0 and 2.9939.2). In both cases the update only landed after I manually downloaded the same .msix from downloads.claude.ai in a browser and double-clicked it, which installs without any error.

What I found while investigating:

  1. The download itself succeeds. The Delivery Optimization log (Get-DeliveryOptimizationLog) shows the first job (caller MSIX HttpsDataSource Download) completing 6 pieces with no HTTP error. A second job then fetches one more piece (download completed) and fails when it writes that piece into the caller's stream:

``
CSwarm::_OnDownloadPieceDone | download completed
CBufferedWriteData::Write | Stream write failed, flushed: 0, to flush: 65535 (new: 65535)
CPiecesToStreamProcessor::_FlushPendingWrites | PSP: Error flushing range {0, 65535} with nextWriteOffset = 0, destFileOffset = 0
CBackgroundCopyJob::NotifyError | ... hr: 8007000d, state: 1
``

So the first 64 KiB of the package is rejected by the consumer (the MSIX streaming staging session) with ERROR_INVALID_DATA.

  1. The deployment then fails (AppXDeploymentServer/Operational):

``
603 Started deployment Add operation on Claude-d3e50475d5d6bb0c317560310200249dd61b87d8.msix (NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse)
495 Common::Deployment::MsixvcStagingSession::GetManifestReader in MsixvcStagingSession failed with error 0x87E80034
402 error 0x87E80034: Reading manifest from location: Claude-d3e50475...msix failed with error: Unknown error
404 AppX Deployment operation failed with error 0x80073CF0
``

gamingservices.exe also connects to downloads.claude.ai at the moment of failure.

  1. The server and the bytes are fine.
  • HEAD requests to https://downloads.claude.ai/releases/win32/x64/2.9939.2/Claude-d3e50475d5d6bb0c317560310200249dd61b87d8.msix return 200, Accept-Ranges: bytes, a stable ETag and Content-Length: 289376204.
  • Range requests return correct 206 responses, and the file starts with PK 03 04.
  • SHA-256 of bytes 0–1 MiB fetched by range request is identical to the first 1 MiB of the browser-downloaded file.
  • My traffic goes through a local system proxy (TUN). Because the bytes match exactly, I don't think the proxy is involved.
  1. The signature is fine. Get-AuthenticodeSignature on the package returns Valid (Anthropic, PBC → DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 → DigiCert Trusted Root G4), and the chain builds with online revocation checking. So this doesn't look like the untrusted-root case that is sometimes reported as 0x87E80034.

My guess: the URI-based (streaming) install path, AddPackage from an https URI → DO → MsixvcStagingSession, rejects this package. The file-based install path accepts it. If the updater downloaded the .msix to a local file first and then called AddPackage on the local path, it would probably work.

What Should Happen?

The background auto-update should download and install the new version, as it does when the same .msix is installed from a local file.

Error Messages/Logs

See the excerpts above. Summary of error codes:

- `0x87E80034`: MsixvcStagingSession::GetManifestReader (Claude main.log, AppX event 495/402)
- `0x80073CF0`: ERROR_INSTALL_OPEN_PACKAGE_FAILED (AppX event 404)
- `0x8007000D`: ERROR_INVALID_DATA, DO stream write for range {0, 65535} (DO log)

Failure count from main.log: 7 on 2026-09-24, 11 on 2026-09-25 and 5 on 2026-09-26, all 0x87E80034.

Steps to Reproduce

  1. Install Claude Desktop for Windows (MSIX) on Windows 11 Pro 26200.9457.
  2. Wait for a new release to be published.
  3. Leave the app running. The hourly update check logs Found an update, downloading and fails with 0x87E80034 within a few seconds, every time.
  4. Download the same .msix in a browser and install it from the file. This succeeds.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop for Windows 2.9939.2 (MSIX); previously 2.7032.0. This is the desktop app's updater, not the CLI.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

  • Windows 11 Pro 10.0.26200.9457, x64
  • Microsoft.GamingServices 38.117.18001.0 (latest in the Store)
  • Claude Desktop log shows [CCD-autoupdate] Disabled: MSIX install and MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗