Claude Desktop 1.12603.1 (Windows): installing a vendored .mcpb extension from the org directory hangs — "installDxtFromDirectory: reply was never sent"

Resolved 💬 2 comments Opened Jun 12, 2026 by gghez Closed Jun 12, 2026

Summary

Since updating Claude Desktop from 1.11847.5 to 1.12603.1 on Windows,
installing vendored .mcpb extensions (ones that ship a populated
server/lib/ with native wheels) from an organization's directory (Team plan)
hangs silently. The extension never installs, the UI sits on "Installing…"
(empty progress bar) or shows nothing, and no error surfaces to the user.

Lightweight extensions still install fine, so this is specific to bundles that
require real extraction.

Environment

  • Claude Desktop 1.12603.1 (Windows, MSIX). Previous build 1.11847.5.
  • Plan: Team, extension distributed via the organization directory

(one-click "Install" from Connectors).

  • The extension is a Python MCP server that vendors its dependencies into

server/lib/ (~3,900 files, ~20 MB .mcpb, native .pyd/.dll included).

Actual behavior

main.log records the download and start of install, then nothing:

[info]  [download:N] Starting download from https://claude.ai/api/organizations/<org>/dxt/extensions/<ext>/download
[warn]  Installing unsigned extension from %TEMP%\dxt-download-*.mcpb

No Successfully installed extension <id> line and no error follow.

The real error is in the renderer log claude.ai-web.log, ~8s later:

[error] Uncaught (in promise) Error: Error invoking remote method
'$eipc_message$_<id>_$_claude.settings_$_Extensions_$_installDxtFromDirectory': reply was never sent

The main-process installDxtFromDirectory IPC handler never returns, so
extraction never happens. On disk, the staging dir %APPDATA%\Claude\dxt-install-*
contains only the copied package.mcpb (nothing extracted), and no folder is
created under %APPDATA%\Claude\Claude Extensions\.

Expected behavior

The extension extracts and installs, as it did on 1.11847.5.

Reproduction

  1. On Claude Desktop 1.12603.1 (Windows, Team plan), publish a vendored Python

.mcpb (~20 MB, a populated server/lib/) to the org directory.

  1. Click Install from Connectors.
  2. Install hangs; claude.ai-web.log logs installDxtFromDirectory: reply was never sent.

This is a regression (controlled experiment)

The byte-identical .mcpb (verified by SHA-256) that installed
successfully on 1.11847.5
fails on 1.12603.1 with the above hang. The only
variable changed is the Claude Desktop version. A ~27 MB vendored bundle also
installed fine on 1.11847.5.

Ruled out: bundle corruption (zip verifies; re-extracts cleanly with an external
unzip tool), illegal/reserved Windows filenames, path length (MAX_PATH),
case collisions, antivirus, disk space, extension-id/name collisions (a brand-new
id fails identically), and bundle size (larger bundles installed on 1.11847.5).

Impact

  • Vendored org extensions cannot be installed on 1.12603.1.
  • Uninstalling a working vendored extension on 1.12603.1 is destructive: it

cannot be reinstalled until this is fixed.

  • 1.12603.1 is the latest published build, so there is no forward fix; the only

workaround is rolling Claude Desktop back to 1.11847.5.

Workaround

Roll back to 1.11847.5 (vendored extensions install normally there).

View original on GitHub ↗

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