[BUG] Legacy Anthropic extensions (Filesystem v0.2.2, manifest_version 0.2) not enrolled in auto-update — break silently on protocol bumps while newer ext-apps extensions update normally (Windows, CDA 1.9255.2)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Two Anthropic-bundled Claude Desktop extensions on the same install are on two different update tracks, and only one of them actually receives auto-updates. When CDA's client protocol bumped to 2025-11-25 (with the new io.modelcontextprotocol/ui extension capability), the newer-format extension (pdf-viewer, manifest_version 0.3) was auto-updated to handle it. The legacy-format extension (Filesystem v0.2.2, manifest_version 0.2) was not, and silently breaks at the initialize handshake.

Anthropic's engineering blog explicitly promises: "Automatic updates: Extensions update automatically when new versions are available." This is not happening uniformly across Anthropic's own extensions.

Side-by-side evidence from the same install:

| | pdf-viewer (auto-updates) | Filesystem (doesn't) |
|---|---|---|
| Folder | ant.dir.gh.anthropic.pdf-server-mcp | ant.dir.ant.anthropic.filesystem |
| manifest_version | 0.3 | 0.2 |
| _update_metadata.json | Present (hash, signatureInfo, downloadedAt, isInternalDxt: false) | Missing |
| Behavior after CDA protocol bump to 2025-11-25 | Auto-updated, negotiates cleanly | Stale build kept running; dies on every init |

Same install, same user, same auto-update settings — only the pdf-viewer-class extension is actually getting updates.

Related issues checked, all distinct:

• #36818 (closed, invalid) — macOS Tahoe beta host pipe issue. This report is Windows stable and resolves cleanly via uninstall+reinstall, proving stale binary not host behavior.
• #27719 — pre-2025-11-25 Node runtime incompatibility. A fresh v0.2.2 binary on the same built-in Node works fine.
• #31864 — manual mcpServers config vs Directory conflict. Zero manual entries in this report.
• #58765 — server-side allowed_directories validation. All paths valid; server still dies on init.

Novel angle: side-by-side evidence from one install that Anthropic's own auto-update path is being applied unevenly across Anthropic-published extensions. This is a Claude Desktop App / Chat bug, not Claude Code CLI — filing here because previous Claude Desktop bugs have been filed in this repo (e.g. #61682, #58765, #46390).

What Should Happen?

Either:

1. Migrate the legacy Filesystem extension to the same delivery system as pdf-viewer-class extensions (manifest_version 0.3, _update_metadata.json enrollment), so it receives auto-updates that fix protocol regressions; OR

1. Backport auto-update enrollment to existing manifest_version 0.2 installs so users with older installs aren't permanently stuck on stale binaries.

Either way, the engineering blog's promise of "extensions update automatically" should hold uniformly for Anthropic-published extensions.

Additionally, the UI should surface extension health visibly — currently a broken bundled extension produces no notification, no badge, no warning. The only signal is [error] Server disconnected buried in a log file at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ that most users will never find.

Error Messages/Logs

**Filesystem (broken) — `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\mcp-server-Filesystem.log`:**


2026-05-26T20:53:17.830Z [Filesystem] [info] Initializing server...
2026-05-26T20:53:17.862Z [Filesystem] [info] Using built-in Node.js for MCP server: Filesystem
2026-05-26T20:53:18.070Z [Filesystem] [info] Server started and connected successfully
2026-05-26T20:53:18.076Z [Filesystem] [info] Message from client: {"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"extensions":{"io.modelcontextprotocol/ui":{"mimeTypes":["text/html;profile=mcp-app"]}}},"clientInfo":{"name":"claude-ai","version":"0.1.0"}},"jsonrpc":"2.0","id":0}
2026-05-26T20:53:19.783Z [Filesystem] [info] Server transport closed
2026-05-26T20:53:19.783Z [Filesystem] [info] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. `console.error('...')` in JavaScript, `print('...', file=sys.stderr)` in python) and it will appear in this log.
2026-05-26T20:53:19.783Z [Filesystem] [error] Server disconnected. For troubleshooting guidance, please visit our debugging documentation
2026-05-26T20:53:19.784Z [Filesystem] [info] Client transport closed


Server transport closes ~1.7s after `initialize` is sent — server never responds to the new `2025-11-25` protocol with the `io.modelcontextprotocol/ui` extension capability. Pattern repeats on every CDA launch until manual uninstall+reinstall.

---

**pdf-viewer (working) — `mcp-server-pdf-viewer.log` on the same machine, same day:**


2026-05-27T13:37:54.596Z [pdf-viewer] [info] Initializing server...
2026-05-27T13:37:54.600Z [pdf-viewer] [info] Using built-in Node.js for MCP server: pdf-viewer
2026-05-27T13:37:55.378Z [pdf-viewer] [info] Server started and connected successfully
2026-05-27T13:37:55.445Z [pdf-viewer] [info] Message from client: {"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"extensions":{"io.modelcontextprotocol/ui":{"mimeTypes":["text/html;profile=mcp-app"]}}},"clientInfo":{"name":"claude-ai","version":"0.1.0"}},"jsonrpc":"2.0","id":0}
2026-05-27T13:37:55.582Z [pdf-viewer] [info] Message from server: {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},"resources":{"listChanged":true}},"serverInfo":{"name":"PDF Server","version":"2.0.0"}},"jsonrpc":"2.0","id":0}
2026-05-27T13:37:55.583Z [pdf-viewer] [info] Message from client: {"method":"notifications/initialized","jsonrpc":"2.0"}
2026-05-27T13:37:55.583Z [pdf-viewer] [info] Message from client: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}
[tools/list completes successfully, handshake done]


Same Node runtime, same machine, same client protocol — but pdf-viewer's server binary speaks `2025-11-25` and returns matching capabilities. Confirms the root cause is a stale server binary on the Filesystem side, not anything host-, runtime-, or OS-level.

Steps to Reproduce

Pre-condition: A Claude Desktop for Windows install with the Filesystem extension v0.2.2 (ant.dir.ant.anthropic.filesystem) installed before CDA's client protocol bumped to 2025-11-25.

1. Let CDA auto-update to a build that negotiates 2025-11-25 on the MCP client side (confirmed on 1.9255.2 (1dc8f7)).

1. Launch CDA. The Filesystem extension toggle still shows "Enabled" with green check; no error surfaced in the chat UI.

1. Open Settings → Extensions → Filesystem → Configure (and/or Developer → Local MCP servers). Filesystem now shows "failed — Server disconnected" with no actionable guidance.

1. Open %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\mcp-server-Filesystem.log. Confirm the pattern: client sends initialize with protocolVersion: "2025-11-25" and the io.modelcontextprotocol/ui capability → server transport closes ~1.7s later with no response → Server disconnected.

1. Inspect %APPDATA%\Claude\Claude Extensions\ant.dir.ant.anthropic.filesystem\. Note: manifest.json shows "manifest_version": "0.2". No _update_metadata.json file is present.

1. For contrast, inspect %APPDATA%\Claude\Claude Extensions\ant.dir.gh.anthropic.pdf-server-mcp\. Note: manifest.json shows "manifest_version": "0.3". _update_metadata.json is present, with hash, signatureInfo, downloadedAt, and isInternalDxt: false. The pdf-viewer log on the same machine confirms it negotiates 2025-11-25 successfully with the same client.

1. Restart CDA, toggle the Filesystem extension off/on, restart Windows — none of these recover the extension. The stale binary remains stale.

Workaround that does recover (but doesn't prevent recurrence):

1. Settings → Extensions → Filesystem → Uninstall.
2. Fully quit CDA including the system tray icon. Wait several seconds.
3. Relaunch CDA → Settings → Extensions → Directory → Connectors → Filesystem → Install.
4. Reconfigure allowed directories from scratch (the previous configuration is not preserved).
5. Filesystem now works — but the freshly-reinstalled folder still has no _update_metadata.json, so the same breakage will recur on the next CDA client protocol bump.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Filesystem v0.2.2 worked correctly until 2026-05-26 ~17:36 UTC. Broke at 2026-05-26 20:53 UTC after Claude Desktop auto-updated. Currently on Claude Desktop 1.9255.2 (1dc8f7).

Claude Code Version

N/A — this is a Claude Desktop App bug, not Claude Code CLI. Claude Desktop for Windows version: 1.9255.2 (1dc8f7).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Filing location rationale: This is a Claude Desktop App / Chat bug, not a Claude Code CLI bug. Filing in this repo because previous Claude Desktop bugs have been filed here (#61682, #58765, #46390, #36818, #31864) and the README directs feedback here.

Files inspected on the reporter's machine (full evidence trail, useful for the triager):

%APPDATA%\Claude\Claude Extensions\ant.dir.ant.anthropic.filesystem\ (broken):

• manifest.json → "manifest_version": "0.2", "version": "0.2.2", "name": "Filesystem"
• dist/, node_modules/, package.json, package-lock.json, icon.png, README.md
• No _update_metadata.json — this is the diagnostic signal
• Persists after uninstall/reinstall: the freshly reinstalled folder still has no _update_metadata.json

%APPDATA%\Claude\Claude Extensions\ant.dir.gh.anthropic.pdf-server-mcp\ (working):

• manifest.json → "manifest_version": "0.3", "version": "1.7.2", "name": "pdf-viewer"
• _update_metadata.json present with: extensionId, version, downloadedAt: 1779825046995 (2026-05-26 18:30 EDT), hash, signatureInfo: {status: "unsigned"}, isInternalDxt: false, plus full embedded manifest

Note on the folder naming convention — possibly informative for whoever investigates:

• Legacy extensions appear under ant.dir.ant.anthropic.<name> (Filesystem)
• Newer Directory-managed extensions appear under ant.dir.gh.anthropic.<name> (pdf-viewer)

The ant vs gh segment may indicate the publishing pipeline (internal Anthropic vs GitHub-based ext-apps directory). If so, this is a structural gap, not a transient one — any other ant.dir.ant.anthropic.* legacy extensions in the wild are likely on the same broken update track and will fail the next time the MCP client protocol bumps.

Suggested triage steps:

1. Audit which Anthropic-published extensions in the Directory still ship with manifest_version: 0.2.
2. Confirm whether the auto-update worker checks for _update_metadata.json presence before attempting any update — if so, legacy installs are deterministically orphaned.
3. Decide whether to migrate v0.2 → v0.3 server-side, or to push an enrollment fix to existing installs.

Severity: Medium-high. Filesystem is among the most-used bundled extensions; users following Anthropic's documented happy path are silently broken by Anthropic's own auto-update of CDA itself. No notification, no UI hint — just [error] Server disconnected in a log file most users will never find. Will keep recurring on every protocol bump until structurally fixed.