What
Plugin binary installation now removes and re-fetches binaries whose on-disk digest doesn't match the manifest, and creates hard links from arch-specific binary names (e.g., tool-aarch64-apple-darwin) to bare names (e.g., tool) for easier execution.
Details
- If a
bin/entry exists but its SHA-256 doesn't match the manifest, Claude logs "removed bin/{name} — it is not the artifact pinned by the manifest" and re-downloads it. - After placement, a hard link from the arch-specific filename to a bare name is created on macOS/Linux when exactly one declared entry derives that bare name (collision-safe).
- Four target triples are recognized for bare-name derivation:
aarch64-apple-darwin,x86_64-apple-darwin,aarch64-unknown-linux-musl,x86_64-unknown-linux-musl. - New telemetry fields track
mismatch_removed_countandbare_placed_countseparately from download and cache-hit counts. - A new validation pass checks
.mcp.jsonand nested MCP server configs for binary references that aren't in thebinariesmap, warning: "bin/{name} is not a shipped file, a declared binaries entry, or a name derivable from the declared entries — the server will fail to start."
Evidence
Mismatch removal (search for "it is not the artifact pinned by the manifest"); validation (search for "Check for a typo against the \"binaries\" map in plugin.json")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
One source agreesOne thing we can check says the same as this entry.
Anthropic's release notes agree
Fixed MCP servers configured via --mcp-config or .mcp.json ignoring a per-server request_timeout_ms, which caused long-running MCP tool…