[BUG] Claude Desktop silently hangs installing any local .mcpb with a deflated entry larger than ~16 KB

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?

Installing a local .mcpb extension bundle in Claude Desktop for Windows — via drag-and-drop, Settings → Extensions → "Install Extension…", or double-clicking the file — does nothing: no install preview dialog, no error dialog, no error in the logs.

This happens for any archive that contains a deflate-compressed entry whose compressed size exceeds roughly 16 KB. Because the official @anthropic-ai/mcpb CLI (mcpb pack) always deflate-compresses entries, effectively every realistically-sized locally-built extension is uninstallable on 1.12603.1. Only near-empty bundles (~2 KB payloads) still install.

The failure is completely silent, so extension authors have no signal about what's wrong — bundles that are fully valid zips (verified: correct headers, sizes, CRCs; inflateRawSync decompresses every entry) simply appear to be ignored.

What Should Happen?

The extension install preview dialog should appear (as it does for tiny bundles and as it did on Desktop 1.11847.5 for the very same bundles), and installation should proceed — or, if the archive is somehow unacceptable, a visible error should be shown instead of an indefinite silent hang.

Error Messages/Logs

With default logging there is nothing. With `DESKTOP_LOG_LEVEL=debug`, `main.log` shows the preview starting and never finishing:


# failing bundle (3 entries, 1.2 MB packed / 4.9 MB unpacked, packed by `mcpb pack`):
2026-06-12 12:51:10 [info] Handling DXT/MCPB file: C:\...\package-win64.mcpb
# ...then silence forever: no "Zip extraction completed", no "Opening extension
# installation preview", no error, no CPU usage.

# identical content repacked with STORED (method 0, uncompressed) entries:
2026-06-12 13:09:27 [info] Handling DXT/MCPB file: C:\...\package-win64-stored.mcpb
2026-06-12 13:09:27 [debug] Zip extraction completed: 3 files, 4926KB uncompressed
2026-06-12 13:09:27 [debug] Opening extension installation preview { ... }
# -> dialog appears, install succeeds, server runs.


Misleading secondary symptom: `claude.ai-web.log` accumulates `Error invoking remote method '...showInstallDxtDialog': reply was never sent` — these fire on window reload because the preview promise never settled, not at the moment of failure.

Steps to Reproduce

1. On Claude Desktop 1.12603.1 / Windows, build any MCP extension whose server/index.js is more than a few tens of KB (e.g. any esbuild-bundled server) and pack it with mcpb pack.
2. Drag the .mcpb into Settings → Extensions (or double-click it).
3. Observe: nothing happens.
4. Repack the identical staging directory with stored (uncompressed) zip entries and install again: the preview appears instantly and installation succeeds.

Minimal standalone repro of the root cause (no Claude Desktop needed), on Node v24.16.0 — the exact runtime the app reports — with yauzl 2.10.0, mirroring the app's unzipFile:

// npm i yauzl@2 ; node repro.mjs <any mcpb-packed bundle with a >16KB entry>
import yauzl from "yauzl";
yauzl.open(process.argv[2], { lazyEntries: true }, (err, zip) => {
  zip.on("entry", entry => {
    zip.openReadStream(entry, (e, rs) => {      // default decompress (inflate)
      let n = 0;
      rs.on("data", c => n += c.length);
      rs.on("end", () => { console.log(entry.fileName, n); zip.readEntry(); });
    });
  });
  zip.on("end", () => console.log("DONE"));     // never reached
  zip.readEntry();
});
// Small entries complete; the first entry over ~16 KB compressed opens its
// stream and then delivers ZERO data events, no error, no CPU — forever.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.11847.5 (same bundles installed fine)

Claude Code Version

Claude Desktop 1.12603.1 (Electron, Node 24.16.0 per main.log startup banner)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Root cause analysis

The install preview path in the main process (handleDxtFile → previewDxtExtension → the yauzl-based unzipFile) opens archives with yauzl.open (yauzl 2.x), which streams each entry from disk via fd-slicer and pipes it through zlib.createInflateRaw(). Under the Node 24.16 runtime bundled with Desktop 1.12603.1, this fd-slicer → zlib pipe deadlocks on backpressure for entries above ~16 KB compressed: zero bytes flow, no error fires, no CPU is consumed, and the preview promise never settles — so no dialog and no error path.

Isolation matrix (all against the same valid bundle; large entry csize=1,048,592, usize=4,438,216):

| Test | Result |
|---|---|
| yauzl.open + openReadStream (default inflate) — the app's code path | HANG (zero data events) |
| yauzl.open + openReadStream({ decompress: false }) (raw, no zlib) | OK — all bytes delivered |
| yauzl.fromBuffer on the same file read into memory (default inflate) | OK — full inflate |
| zlib.inflateRawSync on the entry's compressed bytes | OK — valid stream, correct CRC |
| Same flow, bundle with ~2 KB payload | OK (9 ms) |
| Same flow, bundles with ~25 KB compressed payloads | HANG |
| Identical content repacked with stored (method 0) entries | OK (29 ms) — and installs end-to-end in the app |

Raw-streaming OK + in-memory inflate OK + file-streamed inflate hanging + a size threshold pins the fault on the fd-slicer ReadStream ↔ zlib Transform backpressure interaction under Node 24 — not the archive, zip metadata, manifest, or org blocklist/allowlist (all verified clean).

Suggested fixes

1. Use yauzl.fromBuffer instead of yauzl.open in the preview/install path (bundle sizes are already capped by validation), or
2. upgrade/replace yauzl (v3 or node:stream.pipeline-based plumbing) to survive Node 24 backpressure semantics, or
3. at minimum add a timeout + visible error around the preview unzip so the failure is not silent.

Workaround for extension authors

Pack .mcpb archives with stored (method 0, uncompressed) entries; they bypass the inflate pipeline and install correctly on both 1.11847.5 and 1.12603.1. Note this means mcpb pack in @anthropic-ai/mcpb currently produces archives the matching Desktop version cannot install — a --no-compression option there would help.

Reporter: ddmitov@gmail.com · Found 2026-06-12