[BUG] Desktop extension installs silently fail on macOS Tahoe 26.5 — no error, no feedback

Update and Diagnostic Report

claude-diagnostic-8da4d670-20260614-2326.zip

claude-ai-web-log.txt shows every install attempt fails with:

[error] Uncaught (in promise) Error: Error invoking remote method
'..._$_Extensions_$_installDxtFromDirectory': reply was never sent

This occurs 13 times across the session, once per install attempt. The main
process receives the IPC call, starts the download, logs "Installing unsigned
extension from ...", then silently fails to complete — never sending the IPC
reply. The renderer's promise hangs until timeout.

The actual exception in the main process install handler is not logged anywhere
(main-log.txt, mcp-log.txt, mcp-server-logs.txt are all clean), suggesting an
unhandled rejection or swallowed error in the extension unpacking/installation
code path.

It had the exact same problem.
Just as a quick fix/workaround, I renamed the MCPB to zip, unpacked it and installed it as an unpacked extension - worked

Seeing this too, can't install custom MCPs.

Same symptom on macOS Sequoia, not Tahoe — Claude Desktop 1.12603.1.

Reproducing this installing an org-directory extension (custom connector), but on macOS 15.7.7 (Sequoia, build 24G720) — not Tahoe. Since the symptom is identical with the same Desktop build 1.12603.1, this suggests the regression is in the Claude Desktop build itself, not in macOS Tahoe's sandbox.

Identical behavior to the report:

• main.log: Starting download …/dxt/extensions/<id>/download → [warn] Installing unsigned extension from …/dxt-download-*.mcpb → then nothing (no error, no spawn, no further log).
• ~/Library/Application Support/Claude/Claude Extensions/ stays empty — nothing is ever extracted.
• UI stuck on "Installing…" indefinitely; repeated attempts leave orphaned dxt-download-* temp files.
• The .mcpb is a valid zip (correct manifest.json + bundled node_modules); the same package installs and runs fine on the Linux build 1.3109.0 → macOS-build-specific.
• Org allowlist disabled, blocklist empty, no signature MDM policy set.

Reproducible 100%. Happy to share full logs.

I’m experiencing the same issue as well.

In Korea, the issue started appearing today, June 16, 2026. It seems possible that the issue may have appeared later here due to rollout timing, propagation delay, or network-related factors, although this is only a guess.

After asking several users to test it, we confirmed two successful cases where the issue was resolved on the following operating system version:

• 26.5.1(25F80)

However, the issue still appears to persist on the following operating system version:

• 26.2

I’m sharing this as an additional case report in case it helps with the investigation.

---

Claude for Mac : Claude 1.12603.1 (3df4fd) 2026-06-11T16:57:36.000Z

---

I’m adding the technical specifications below.

The following is a technical case record for a failed case on OS version 26.2:

• Node installed on the OS: 22.6.0
• Python installed on the OS: 3.14.0

However, the versions detected and used by Claude appear to be slightly different:

• Embedded Node used by Claude Desktop: 24.16.0
• Python versions detected by Claude Desktop: 3.9.6 and 3.14.0

It is not clearly indicated which version is actually being used.

Same here — Claude Desktop 1.12603.1, macOS 26.4.1 (build 25E253). Two data points to add:

The local double-click path is broken too, not just directory/connector installs. Most reports here are org-directory installs (the installDxtFromDirectory IPC). I'm hitting the identical silent failure via the other entry point — double-clicking a downloaded .mcpb from Finder. main.log logs Handling DXT/MCPB file: …/x.mcpb and then nothing: no unpack, no error, the manifest is never even read, installed version never changes. Reproduced across a full app restart, a reboot, and fresh re-downloads. So both the directory path and the local-file-open path dead-end under this build.

Confirming 26.4.1 is still affected. Adding to the OS matrix: pollra noted 26.5.1 resolved for some but 26.2 persists — 26.4.1 (build 25E253) is also still broken.

The .mcpb is a valid zip (correct manifest.json + bundled node_modules; passes mcpb validate and boots fine when the bundled server is run directly with node). Org allowlist disabled, blocklist empty, unsigned/local — all permitted. Purely the Desktop-side install/unpack that fails.

Same symptom here on macOS, but with a local .mcpb install (not from the Directory) — which suggests the silent-failure is in the install/unpack stage, not the download path.

Environment

• macOS (Apple Silicon)
• Claude Desktop (latest as of 2026-06-16)
• Local .mcpb bundle, not from the Directory

Steps to reproduce

1. Settings → Extensions → Install Extension…
2. Select a local .mcpb file (in my case p58-n8n-0.2.20-demo.13.mcpb, ~4.26 MB, manifest_version: 0.3)
3. Confirm in the dialog

Result

File is silently rejected. No error, no toast, no entry in the installed-extensions list, no progress indicator. Identical "looks like nothing happened" UX to #68484.

Bundle is valid

$ file p58-n8n-0.2.20-demo.13.mcpb
p58-n8n-0.2.20-demo.13.mcpb: Zip archive data, at least v2.0 to extract, compression method=deflate

$ unzip -l p58-n8n-0.2.20-demo.13.mcpb | head -5
  Length      Date    Time    Name
---------  ---------- -----   ----
  2817205  2026-06-14 11:35   dist/mcp/server.bundle.cjs
    77612  2026-06-14 11:35   icon.png
     2947  2026-06-14 11:35   manifest.json

Manifest is manifest_version: 0.3, valid node-server entry point.

Why this matters for triage

The original report covers Directory-sourced installs. This adds a local-.mcpb-via-file-picker repro with the same silent-failure signature, which points the bug at the install/unpack pipeline rather than anything in the download path or Directory metadata. At minimum, any failure mode in the install pipeline should surface a user-visible error.

Happy to attach the bundle, full main.log excerpt, or check for orphaned dxt-install-* staging directories if useful.

After updating Claude, I confirmed that it now works properly on Tahoe 26.2.

Claude version: Claude 1.13576.0 (1290fc) 2026-06-16T05:46:10.000Z

Sharing this as an additional reference.

For reference, I could not find any mention of this issue in the available update notes.

• Claude release notes: https://support.claude.com/en/articles/12138966-release-notes
• Claude core changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

@pollra thank you for the headup as i just updated my claude desktop and now it works! Thank you!!!

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Confirming this is still reproducible on a much later build — same failure signature, ~2 months after the original report.

Environment

• Claude Desktop: 1.26832.0 (056ee2), build date 2026-08-06T05:43:05.000Z
• macOS: 26.5.2 (Build 25F84)
• Hardware: Apple Silicon

Extensions tested (same as OP)

• Macos (ant.dir.gh.cursortouch.macos-mcp) — install fails
• Control your Mac (ant.dir.gh.k6l3.osascript) — install fails

Symptom
Clicking Install in Settings → Extensions → Browse Extensions (Connectors Directory) results in "Failed to install extension." No extension appears in the installed list afterward.

Notes

• Reproduces on a build released ~2 months after this issue was originally filed (1.12603.1 → 1.26832.0), so the underlying install pipeline issue does not appear to have been fixed in that window.
• Same macOS minor release line as the original report (26.5.x), one point release ahead (26.5.1 → 26.5.2).
• Behavior differs slightly from the original report in that an explicit "Failed to install extension" error is now shown, rather than a silent no-op / indefinite progress bar. This may indicate a partial fix was shipped that surfaces the failure to the user, without resolving the underlying extraction/install failure itself.

Happy to attach main.log excerpts if useful — will look for the same "Installing unsigned extension" → silence/error pattern described above.