[BUG] Cowork "Progress" panel shows false "tool not found" for Desktop Commander (Windows, after app update)

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?

On Windows, after a recent Claude Desktop auto-update, the Cowork right-side "Progress" panel repeatedly shows orange warning chips such as:

• tool Desktop_Commander__write_file not found
• tool Desktop_Commander__get_config not found
• tool Desktop_Commander__list_directory not found
• tool Desktop_Commander__read_file not found
• tool Desktop_Commander__edit_block not found

These chips line up 1:1 with the sequence of Desktop Commander tool calls actually being made in the same conversation, but the calls themselves succeed (their results are visible in the transcript). A separate "Used Desktop Commander integration -> Unable to reach Desktop Commander" card also appears once, which correlates with a brief real reconnect gap right after restarting the app (expected), not an ongoing outage.

While debugging this with the user, we also found and fixed a real, separate issue: a second, independently-installed "Filesystem" MCP extension was registering 14 tool names that exactly collide with Desktop Commander's own tools (read_file, write_file, list_directory, get_file_info, move_file, create_directory). Disabling that extension removed exactly 14 tools from the proxied tool list (185 -> 171) and was a legitimate fix, but it did NOT stop the "not found" chips from appearing afterward.

Across the same debugging session, the fully-qualified tool (mcp__remote-devices__Desktop_Commander__*) was called dozens of times directly and every single call succeeded with real data returned. No crash/error/restart entries were found in mcp-server-Desktop Commander.log or mcp.log correlating with the chip timestamps.

What Should Happen?

The Progress panel should accurately reflect whether a tool call succeeded or failed, and should not show "not found" for tools that are actually executing successfully.

Best guess at root cause: the panel appears to resolve its display label/icon using a shortened tool name (Desktop_Commander__<tool>) instead of the fully-qualified proxied name (mcp__remote-devices__Desktop_Commander__<tool>) that is actually used for execution, and falls back to an error/"not found" state when that secondary lookup misses -- even though the real tool call succeeded.

Error Messages/Logs

Environment:
- OS: Windows 11 (win32/x64)
- Claude Desktop app version: 1.20186.0 (Electron 42.5.1, MSIX package Claude_pzs8sxrjxfjjc)
- Extension: Desktop Commander (ant.dir.gh.wonderwhy-er.desktopcommandermcp), manifest v0.2.43, installed via Claude Extensions (DXT)
- Feature: Cowork / remote-devices bridge ("local agent mode")
- User reports this started right after a Claude Desktop auto-update; not present before.

Steps to reproduce:
1. Install Desktop Commander as a Claude Desktop extension on Windows, use it via a Cowork/remote session.
2. Make several Desktop Commander tool calls (read_file, write_file, edit_block, list_directory, get_config) within one conversation.
3. Watch the right-side Progress panel -- chips reading "tool Desktop_Commander__<name> not found" appear for calls that actually succeeded (visible in the transcript).

Related existing reports:
- #38783 - Windows: Cowork browser automation tools missing after a Claude Desktop update (VM-to-host bridge fails to register tools). Closed as "not planned". Same general category (post-update tool-registration/bridge issue on Windows), different specific tools.
- #51145 - Cowork Progress widget does not refresh / reflects stale state. Confirms the Progress widget has had separate accuracy bugs before.

Also observed: Desktop Commander is additionally spun up via `npx -y @wonderwhy-er/desktop-commander@latest` specifically for local-agent-mode/Cowork sessions, separate from the pinned v0.2.43 DXT bundle used by the regular chat UI. Worth confirming this is intentional and consistently version-pinned.

Impact: cosmetic/confidence issue, not a functional blocker -- Desktop Commander itself keeps working -- but it is confusing and makes users think their MCP setup is broken when it isn't.

Steps to Reproduce

1. Install the Desktop Commander MCP extension in Claude Desktop on Windows (Claude Extensions / DXT).
2. Open or use a Cowork / remote-devices ("local agent mode") session.
3. Make several Desktop Commander tool calls in the same conversation, e.g.: get_config, read_file, list_directory, edit_block, write_file, start_process.
4. Watch the right-side "Progress" panel in the Cowork sidebar while the calls are running.
5. Observe: chips like "tool Desktop_Commander__read_file not found" / "tool Desktop_Commander__edit_block not found" appear next to calls that actually succeeded -- the same tool's real output/data is visible in the conversation transcript at the same time.
6. This can be verified independently of any specific tool: re-run the exact same call again later in the same conversation and it succeeds again with correct data, while the Progress panel still shows (or re-shows) a "not found" chip for it.

User-reported context: this behavior was not present before a recent Claude Desktop auto-update on Windows, and started immediately after.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A (Claude Desktop app, not Claude Code CLI) -- Claude Desktop app version 1.20186.0 on Windows

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Note: this bug report was filed via the standard Claude Code bug-report template, but the issue itself is in the Claude Desktop app's Cowork UI ("Progress" side panel), not the Claude Code CLI -- hence "N/A"/"Other" on the CLI-specific fields above (Claude Code Version, Platform, Terminal/Shell). Model in use during the observed session was Claude Opus 4.8 (as shown in the Cowork chat UI). See the "Steps to Reproduce" and "Error Messages/Logs" sections for full technical detail gathered while debugging this with the user (including the related issues #38783 and #51145, and the Desktop Commander tool-name-collision fix that was applied but did not resolve this specific symptom).