Installing .mcpb

[oviedomarco1]

[BUG] Claude Desktop 1.12603.1.0 (Windows/MSIX): Install Extension window closes silently when opening any .mcpb file

Since auto-updating to 1.12603.1.0 (Microsoft Store build) on 2026-06-11, installing any local .mcpb via Settings → Extensions → Install Extension crashes: after selecting the file and clicking "Preview", the window closes and nothing happens. No entries appear in main.log and no Crashpad dump is generated.
Reproduced with 3 different bundles: two packed with Compress-Archive, one packed with the official @anthropic-ai/mcpb CLI (pack). All pass mcpb validate. One of them installed successfully on the previous Desktop version days ago. "Install Unpacked Extension" with the same manifest + binary works correctly, so the regression is isolated to the .mcpb install/preview flow.

Environment: Windows 11 Pro 26200, Claude Desktop 1.12603.1.0 (MSIX Claude_pzs8sxrjxfjjc), org blocklist empty, allowlist disabled, extensions unsigned (local).

[csegura]

Same here:

Summary

On Claude Desktop 1.12603.1 (Windows), installing our organization's
custom desktop extension (xxx-connector, a node-type .mcpb) never completes.
The package downloads and is staged to a dxt-install-* temp folder, but Claude never extracts
it and never registers the extension. No error is logged. The same files loaded "unpacked"
(developer mode) install and run perfectly, so the connector and its manifest are valid.

We have ruled out signature policy, the org extension allowlist, and the package itself.

Environment

• Claude Desktop 1.12603.1, Windows (Program Files\WindowsApps\Claude_1.12603.1.0_x64__pzs8sxrjxfjjc)
• Extension type: node (runs on Claude's built-in Node), connects to an internal MCP server over the LAN

Observed behavior (from %APPDATA%\Claude\logs\main.log)

Every install attempt looks like this and then stops — no further lines about this install:

[download:1] Starting download from https://claude.ai/api/organizations/5b8a.../dxt/extensions/ant.dir.ant.0x10505a6d.xxx-connector/download
[warn] Installing unsigned extension from C:\Users\...\AppData\Local\Temp\dxt-download-<id>.mcpb
   (… nothing further: no extraction, no "Successfully installed", no error …)

• %APPDATA%\Claude\extensions-installations.json stays { "extensions": {} }.
• Each staging folder %APPDATA%\Claude\dxt-install-*/ contains only package.mcpb — the file is staged but never unzipped.
• The unpacked path, by contrast, logs:
  Successfully installed extension local.unpacked.….xxx-connector v0.1.1
  and the MCP server runs: Using built-in Node.js for MCP server … Server started and connected successfully (and returns real data).

What we ruled out

1. Signature requirement — HKLM\SOFTWARE\Policies\Claude\isDesktopExtensionSignatureRequired = 0 (and WOW6432Node). The log proceeds past Installing unsigned extension as a warning, so signature is not the gate.
2. Org desktop-extension allowlist — we disabled it (Organization allowlist enabled: false); install still stalls identically.
3. The package — the file Claude actually downloaded (dxt-download-<id>.mcpb) is a valid zip and is byte-identical to our build:
   • sha1 = 33be3467a9c3eef10ea7d621535a5b7acb1ae8d0, size 62926 bytes
   • 3 entries (manifest.json, server/index.cjs, icon.png), no ZIP data descriptors, zipfile.testzip() passes, packed with fflate.zipSync (same library as the official @anthropic-ai/mcpb tool)
   • manifest_version: "0.3", valid against the mcpb schema.
4. Org directory — earlier, installDxtFromDirectory also returned HTTP 404 for the same extension URL, separate from the staging/extract failure.

Reproduction

1. Publish a custom node-type .mcpb to an org's desktop extension directory.
2. From a managed Windows client (signature requirement off, allowlist off), install it from the directory or from the downloaded file.
3. Observe: file stages to dxt-install-*/package.mcpb, never extracts; extensions-installations.json stays empty; no error logged.
4. Load the identical files via "Install unpacked extension" → works.

Why does the desktop client stage the .mcpb but never run the extraction/registration step, with no error logged? Is there an endpoint-security or extraction-worker condition that fails silently on 1.12603.1? Please advise on a fix or diagnostic logging we can enable.