Bug Report: Claude Desktop `1.1.3647 (8f7c53) 2026-02-19T15:02:19.000Z` can't install signed extensions

[oshchyhol]

Describe the bug
Claude 1.1.3647 (8f7c53) 2026-02-19T15:02:19.000Z can't install signed extensions.

To Reproduce
Steps to reproduce the behavior:

• Build and sign your bundle
• Developer > Extensions > Install Extension... > click "Preview"

Expected behavior
Both signed and unsigned extensions can be previewed and installed successfully.

Additional context
The unsigned extensions can be previewed and installed just fine.
This error is also reproducible when attempting to install

• self-signed extensions
• already published signed production extensions
  Just in case, mcpb verify and mcpb info have been broken since ages: always reporting ERROR: Extension is not signed. The root cause was described here: ERROR: Extension is not signed #21 (comment)

[vcolin7]

I found the same issue when building my own signed MCP bundles. The cause seems to be that the ZIP parser in Claude Desktop expects the EOCD comment_length field in the ZIP file to match the signature length in bytes. Both the MCPB CLI in this repo and the .NET port I'm using simply append the signature to the ZIP without setting a value for comment_length. The challenge here is that you can't just update it after the fact, as the signature would not match the ZIP if the latter has been modified since the former was generated; and we can't know the size of the signature beforehand.

That said, you could do what I did:

1. Set the EOCD comment_length in your unsigned MCPB to an arbitrary high number of bytes the signature should not exceed (e.g. 16384 bytes in my case)
2. Generate a detached PKCS#7 signature for your MCPB.
3. Pad the signature with zeroes so it's the same length we previously set and append it according to the spec with a small caveat:

   [Original ZIP content including EOCD's comment_length]
   MCPB_SIG_V1                           ← ASCII marker (11 bytes)
   [4-byte little-endian length prefix]  ← length of the DER signature << Undocumented but necessary
   [DER-encoded PKCS#7 signature]        ← ~4 KB typically
   MCPB_SIG_END                          ← ASCII marker (12 bytes)
   

   Note: The difference between this and the official spec is merely a doc discrepancy, the actual code in distributed in NPM and NuGet does in fact use a length prefix.

The signature should be valid for mcpb info and mcpb verify. If the NPM implementation does not work for you, you can try the .NET one I mentioned above.

It's not pretty and I don't know if there's a better way, but it's something and it works 🤷🏾‍♂️.

[vcolin7]

@joan-anthropic, @asklar should we expect the mcpb CLI to handle EOCD updating or do you think we should report this to Claude Desktop instead so their ZIP parser is more flexible?

[vcolin7]

@oshchyhol You can see how we handle the signature padding for the Azure MCP Server here and here

[bryan-anthropic]

Thank you for the detailed analysis, @vcolin7. We've confirmed the root cause: the signing function appends the signature block without updating the ZIP EOCD comment_length field, which causes strict ZIP parsers to reject the file.

A fix has been submitted in #204 that updates the EOCD comment_length to account for the appended signature block before writing.