## Environment - **Claude Desktop:** 1.21459.0 (macOS, auto-updated 2026-07-14 ~06:11 local; binary + `app.asar` mtimes confirm) - **OS:** macOS (Darwin 25.5.0, Apple Silicon) - **Extension:** any locally-installed `.mcpb` (reproduced with two different bundles, `manifest_version: "0.3"`, `server.type: "binary"`, unsigned, `source: local`) ## Summary After today's Desktop auto-update, the Settings → Extensions pane fails to load whenever **at least one** extension is installed. The extension

[BUG] Claude Desktop 1.21459.0 (macOS): Extensions settings pane fails to load when any .mcpb extension is installed — TypeError: u._parse is not a function (dual zod v3/v4)

Status Fixed / completed

Maintainer reply None cached

Activity 9 comments · opened Jul 15, 2026 · closed Aug 25, 2026

Environment

Claude Desktop: 1.21459.0 (macOS, auto-updated 2026-07-14 ~06:11 local; binary + app.asar mtimes confirm)
OS: macOS (Darwin 25.5.0, Apple Silicon)
Extension: any locally-installed .mcpb (reproduced with two different bundles, manifest_version: "0.3", server.type: "binary", unsigned, source: local)

Summary

After today's Desktop auto-update, the Settings → Extensions pane fails to load whenever at least one extension is installed. The extension itself installs and runs fine (files extracted, can_install: true, MCP server launches and answers tools/list) — only the management UI is dead, which makes it look like the install failed and leaves no way to manage extensions from the UI.

The same .mcpb files (including one that had been installed unchanged for days) rendered fine in the pane before the app update. With zero extensions installed, the pane loads.

Renderer error (claude.ai-web.log)

2026-07-14 21:24:50 [error] Uncaught (in promise) Error: Error invoking remote method
'$eipc_message$_..._$_claude.settings_$_Extensions_$_getInstalledExtensionsWithState':
TypeError: u._parse is not a function

Fires on every Extensions-pane load / post-install refresh. Never appears in logs prior to the 1.21459.0 update; appears on every install afterward, including a re-install of a months-old bundle.

Root cause (from the shipped bundle)

In app.asar → .vite/build/index.chunk-Bm6k9gCR.js, the installed-extension-state schema embeds the MCPB manifest schema across two different bundled copies of zod:

// app's own zod copy (v3-style: shape members get ._parse called)
AOt = Ue({
  settings: kze,
  path: be(),
  displayName: be(),
  signatureInfo: $Ot().optional(),
  manifest: $ze,          // <-- foreign schema
  id: be()
});

// $ze is @anthropic-ai/mcpb's McpbManifestSchema, built with a DIFFERENT zod copy
$ze = Ose;                 // ...{ McpbManifestSchema: Ose } ...
Ose = Je([UB, jB, BB, HB]) // union of manifest v0.1/0.2/0.3/0.4 schemas

The chunk contains both zod v3 internals (_parse method definitions) and zod v4 internals (_zod core markers, ~493 occurrences). The result validator for the IPC method is:

CLt(e){ return AOt.safeParse(e).success }
// wrapper: if(!(Array.isArray(i) && i.every(s => CLt(s)))) throw ...

AOt (zod v3 object) walking its shape calls manifest._parse(...) on McpbManifestSchema — a zod-v4 schema with no _parse → TypeError: u._parse is not a function, thrown inside the main-process handler, surfaced to the renderer as "Error invoking remote method", and the pane never gets its data.

Because manifest is a required key present for every installed extension, any installed extension with any manifest triggers this. An empty extensions list short-circuits .every, which is why the pane only works when nothing is installed. Likely regression vector: @anthropic-ai/mcpb (or the schema module) moved to zod v4 while the app code embedding McpbManifestSchema inside its own z.object still runs zod v3.

Repro

Claude Desktop 1.21459.0 on macOS, no extensions installed → Settings → Extensions loads fine.
Install any local .mcpb (double-click). Install reports success in main.log; extension server launches and serves tools/list.
Open Settings → Extensions → pane fails to load; renderer log shows the u._parse error on getInstalledExtensionsWithState.
Remove ~/Library/Application Support/Claude/extensions-installations.json + Claude Extensions/ → pane loads again. Reinstall → broken again. Fully deterministic.

Impact

Extensions management UI is unusable for anyone on 1.21459.0 with ≥1 installed extension; installs appear to fail (they don't — servers run fine).
No UI path to configure/disable/uninstall extensions; users are hand-editing app-support JSON to recover.
As an extension publisher (Vibrai), every customer who takes today's Desktop update hits this against our published, previously-working .mcpb.

View original on GitHub ↗

9 Comments

terry623 · 1 month ago

I’m experiencing the same issue on both macOS and Windows.

Hope the Anthropic team can investigate this and provide a fix as soon as possible.

gitizenme · 1 month ago

Why invalid? - Claude wrote this bug report 🤣

njkdev · 1 month ago

Confirming on macOS (Apple Silicon), Claude Desktop 1.21459.0. Same error, same repro: pane loads with zero extensions, breaks permanently after installing one.

Worth noting: this reproduces on a completely fresh install (app + all app data deleted, reinstalled, clean sign-in), so it's the build, not local state. And per the OP, installs do succeed — the MCP server runs fine in conversations; only the management UI is broken.

Also this is Claude Desktop, not Claude Code — the invalid label looks like bot mistriage.

Fl0p · 1 month ago

Same issue
invalid cause Claude Desktop != Claude Code

ChickBun · 1 month ago

Extensions requiring post-install configuration (e.g. official Filesystem extension) get stuck permanently disabled, since the config step needs the same broken panel — unlike extensions with no config step, which apparently still run. Extensions are completely broken for me, no way to install, it just breaks.

I'm on Windows (ARM CPU).

jordi-planview · 1 month ago

Confirming on all windows and macOS machines with version Claude 1.21459.0 (f7518f) 2026-07-14T05:32:17.000Z to have this issue and blocking managing extensions.

Marc-- · 1 month ago

Confirming this reproduces on Linux too, not just macOS — same root cause looks applicable.
Environment:

Claude Desktop: 1.21459.0 (Ubuntu 26.04, amd64, official apt repo — downloads.claude.ai/claude-desktop/apt/stable)
Extensions tested: a custom unsigned .mcpb (internal GitLab proxy, manifest_version: "0.2") and the official Figma extension from the directory. Both trigger the identical failure.

Behavior: identical to what's described above — Settings → Extensions pane shows "Chargement des extensions..." indefinitely and never resolves.

Renderer error:
Error invoking remote method '$eipc_message$_..._$_claude.settings_$_Extensions_$_getInstalledExtensionsWithState': TypeError: u._parse is not a function

Confirmed the extension itself is unaffected — the MCP server launches fine and answers tools/list/search normally in conversation; only the management pane is broken. With zero extensions installed, the pane loads fine, matching the "empty list short-circuits .every" explanation above.

gitizenme · 1 month ago

On the invalid label: understood this repo is Claude Code's tracker, but Claude Desktop has no public issue tracker, and Desktop-side reports have lived here before (#28775, #67919). Leaving this open for whoever can route it internally — meanwhile, sharper root-cause evidence for the Desktop team:

Desktop 1.21459.0's bundle (app.asar → package.json, @ant/desktop) declares "@anthropic-ai/mcpb": "2.1.2" and "zod": "catalog:".
The published @anthropic-ai/mcpb package is not at fault: both the 1.x and 2.x lines on npm import the plain zod (v3) API with "zod": "^3.25.67" — no zod/v4 imports anywhere in their published dist.
Yet in the shipped main-process chunk (.vite/build/index.chunk-Bm6k9gCR.js), the McpbManifestSchema instances are zod-v4-flavored (_zod internals), while the extension-state schema embedding them under its manifest: key is zod-v3-flavored (walks children via the v3 _parse protocol). Both runtimes are physically present in that one chunk (v3 _parse method definitions and ~493 _zod markers).
So the v4 flavor of the manifest schemas is a build-graph resolution effect inside the Desktop monorepo (e.g. pnpm catalog/overrides resolving mcpb's from "zod" imports to a zod-4 install) while another module kept a genuine v3 copy.

Minimal repro of the failure class:

import { z as z3 } from "zod";     // v3 API
import { z as z4 } from "zod/v4";  // v4 API — ships in the same zod@^3.25 install
z3.object({ manifest: z4.object({}) }).safeParse({ manifest: {} });
// TypeError: ..._parse is not a function

Fix direction: make the extension-state wrapper and the manifest schemas resolve to the same zod API — or stop embedding the imported schema object directly and validate the manifest field via the mcpb package's own parse entry point.