mcpb-binary-spawn.log
Preflight
Environment
-
Claude Desktop (macOS), Apple Intel x86_64 host.
-
Extension: a single MCP server frozen with PyInstaller (onedir), server.type: "binary", entry_point: server/, mcp_config.command: "${__dirname}/server/".
-
The extension is spec-valid: mcpb validate passes; the launcher is a Mach-O 64-bit executable x86_64; the onedir tree server/_internal/ with the bundled Python, libssllibcrypto, native .sos) is complete.
-
Per the repository README and the MCPB blog post, binary is a documented, supported server type.
Steps to reproduce
-
Extract the bundle, preserving the executable bit, and confirm +x:
ditto -x -k bundle.mcpb unpacked/
chmod +x unpacked/server/<launcher>
-
Claude Desktop → Settings → Extensions → Install Unpacked Extension → select unpacked/.
-
Install succeeds: Successfully installed extension local.unpacked.<...>.
-
The server fails to start immediately and on every retry.
Expected
The host launches the binary server (it does so when the same command is configured manually — see "What works").
Actual
The extension log shows the host fail to recognize the binary server type, fall back to "basic execution", and then fail to spawn the process:
[info] Launching MCP Server: <name>
[info] Using basic execution for extension <name>: not a Node.js server or a Python server or no entry point specified
[info] Using MCP server command: server/<launcher> with args and path: { ... paths: [ /usr/local/bin, /usr/bin, ... ] }
[info] Server started and connected successfully
Failed to spawn process: No such file or directory
[error] Server disconnected.
The spawn fails with *No such file or directory (ENOENT)**, not Permission denied (EACCES). The launcher exists and is executable (it runs when invoked directly), so this is a path/handler-resolution failure, not a missing exec bit.
Editing the installed manifest to an absolute command does not help
Rewriting mcp_config.command in the installed manifest to an absolute path changes nothing: the host then stops logging Using MCP server command: … entirely and goes straight to Using basic execution …. So this is not merely a working-directory problem for a relative command — the unpacked install path appears to have no working handler for server.type: "binary": it is treated as "no entry point specified" and routed to a generic exec that never launches the declared binary.
What works — the artifact is sound
-
Run directly from the extraction dir, the launcher starts and speaks MCP over stdio and exits cleanly exit 0).
-
Wired manually via claude_desktop_config.json with an absolute command (the developer path, shown as LOCAL DEV), the server spawns and its tools are usable. Confirmed repeatedly.
So the failure is in the host's unpacked-launch path for type: binary, not in the binary, the manifest, or permissions.
Scope note
This report covers the Install Unpacked Extension path specifically. I could not separately exercise the one-click .mcpb install path for a binary bundle: a signed bundle is rejected at unzip (see #278), and the unsigned bundle's install preview did not engage. So whether the non-unpacked install path has a working binary handler is untested here.
Suggested direction
In the unpacked/dev install path, route server.type: "binary" to the same binary launch handler used for installed bundles — resolve ${__dirname}, set the working directory to the extension root, and spawn the declared launcher — instead of falling back to "basic execution".
Related
mcpb-binary-spawn.log
Preflight
mcpb signproduces bundles that strict zip parsers reject - including Claude Desktop itself ("Invalid comment length") #278; mcpb verify is addressed by fix: makemcpb verify/infoactually verify PKCS#7 signatures #255; +x preservation in pack by Fix: Preserve file permissions when packing binary executables #14. None covers this unpacked binary-launch failure.Environment
Claude Desktop (macOS), Apple Intel x86_64 host.
Extension: a single MCP server frozen with PyInstaller (onedir), server.type: "binary", entry_point: server/, mcp_config.command: "${__dirname}/server/".
The extension is spec-valid: mcpb validate passes; the launcher is a Mach-O 64-bit executable x86_64; the onedir tree server/_internal/ with the bundled Python, libssllibcrypto, native .sos) is complete.
Per the repository README and the MCPB blog post, binary is a documented, supported server type.
Steps to reproduce
Extract the bundle, preserving the executable bit, and confirm +x:
Claude Desktop → Settings → Extensions → Install Unpacked Extension → select unpacked/.
Install succeeds: Successfully installed extension local.unpacked.<...>.
The server fails to start immediately and on every retry.
Expected
The host launches the binary server (it does so when the same command is configured manually — see "What works").
Actual
The extension log shows the host fail to recognize the binary server type, fall back to "basic execution", and then fail to spawn the process:
The spawn fails with *No such file or directory (ENOENT)**, not Permission denied (EACCES). The launcher exists and is executable (it runs when invoked directly), so this is a path/handler-resolution failure, not a missing exec bit.
Editing the installed manifest to an absolute command does not help
Rewriting mcp_config.command in the installed manifest to an absolute path changes nothing: the host then stops logging Using MCP server command: … entirely and goes straight to Using basic execution …. So this is not merely a working-directory problem for a relative command — the unpacked install path appears to have no working handler for server.type: "binary": it is treated as "no entry point specified" and routed to a generic exec that never launches the declared binary.
What works — the artifact is sound
Run directly from the extraction dir, the launcher starts and speaks MCP over stdio and exits cleanly exit 0).
Wired manually via claude_desktop_config.json with an absolute command (the developer path, shown as LOCAL DEV), the server spawns and its tools are usable. Confirmed repeatedly.
So the failure is in the host's unpacked-launch path for type: binary, not in the binary, the manifest, or permissions.
Scope note
This report covers the Install Unpacked Extension path specifically. I could not separately exercise the one-click .mcpb install path for a binary bundle: a signed bundle is rejected at unzip (see #278), and the unsigned bundle's install preview did not engage. So whether the non-unpacked install path has a working binary handler is untested here.
Suggested direction
In the unpacked/dev install path, route server.type: "binary" to the same binary launch handler used for installed bundles — resolve ${__dirname}, set the working directory to the extension root, and spawn the declared launcher — instead of falling back to "basic execution".
Related
mcpb signproduces bundles that strict zip parsers reject - including Claude Desktop itself ("Invalid comment length") #278 — mcpb sign produces bundles that strict zip parsers reject Invalid comment length); the separate signing/unzip install wall.macOS: UtilityProcess rejects third-party native Node modules due to library validation (distinct from #180) #229 — macOS UtilityProcess rejects third-party native Node modules under library validation (different mechanism; native-module validation, not binary-server routing).
fix: make
mcpb verify/infoactually verify PKCS#7 signatures #255 — PR: make mcpb verifyinfo actually verify PKCS#7 signatures.Fix: Preserve file permissions when packing binary executables #14 — PR: preserve file permissions when packing binary executables (adjacent: the +x bit must survive packing and extraction).