[BUG] Claude Desktop: external stdio MCP tools announced but never dispatched in Chat mode (zero tools/call) — Windows/macOS/Linux, all install types

Confirming the same regression on Claude Desktop 1.24012.1.0 (same MSIX package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc). A few extra data points that narrow it down further:

• Reproduces with the server launched via wsl.exe (Windows → WSL: node inside WSL → @modelcontextprotocol/server-filesystem), so it isn't specific to a Windows-native Node install.
• Two independent external stdio servers (two different WSL distros) fail simultaneously and identically — not server-instance-specific.
• The built-in "Claude in Chrome" MCP works normally in the same session, so the regression is specific to external stdio MCP servers in Chat mode; built-in MCP is unaffected.
• Same signature as reported: mcp.log shows initialize + tools/list succeeding, but no tools/call is ever logged; even list_allowed_directories fails.

Net: healthy initialize/tools/list with a total absence of tools/call points to a client-side dispatch regression for external stdio servers in Chat mode. Claude Code CLI is unaffected (separate config path), consistent with the original report.

Seeing the exact same symptom on Claude Desktop, but with a different MCP server (a custom/internal MCP server, not Filesystem), looks like a general MCP tools/call dispatch failure in Desktop.

Environment:

Claude Desktop (same recent build affected by this issue)
MCP server: custom internal server (unrelated to Filesystem)
Every tool call fails immediately, including simple read-only/no-argument calls

Behavior matches what's described here: the server starts and completes the handshake (initialize + tools/list both succeed), but no tools/call message is ever sent afterward. Same server config works fine when invoked through Claude Code CLI.

Confirming the same regression on Windows 11, Claude Desktop 1.24012.1 (MSIX package Claude_1.24012.1.0_x64__pzs8sxrjxfjjc), official Filesystem extension, extension-managed built-in Node.js.

Since the report lists "Last Working Version: No response" and main.log was missing on that install — I have it, so here is the version history and the before/after data.

Version transition (main.log, local time, UTC+2):

2026-07-20 09:30:38   appVersion 1.22209.3   CCD 2.1.215   working
  ... 10 further starts, unchanged ...
2026-07-21 16:34:27   appVersion 1.22209.3   CCD 2.1.215   working
2026-07-22 05:47:48   appVersion 1.24012.0   CCD 2.1.215   broken
2026-07-22 05:49:08   appVersion 1.24012.1   CCD 2.1.217   broken

Both updates were automatic on quit/restart. No configuration change on my side. Note the CCD bump 2.1.215 -> 2.1.217 alongside the app version.

tools/call before and after (mcp-server-Filesystem.log, UTC). The extension has been in daily use since April:

2026-07-19    21 tools/call
2026-07-20    14 tools/call
2026-07-21    19 tools/call   last one: 2026-07-21T18:18:39.471Z
2026-07-22     0 tools/call   across 8 sessions

The first session after the update begins at 2026-07-22T03:47:49Z, which is the 1.24012.0 launch. Every session from that point on is broken; every session before it worked. Today: 8 server sessions, 8 successful tools/list, zero tools/call.

Handshake is healthy in all 8 of them, e.g.:

2026-07-22T05:03:59.874Z [Filesystem] Initializing server...
2026-07-22T05:03:59.875Z [Filesystem] Using built-in Node.js for MCP server: Filesystem
2026-07-22T05:03:59.893Z [Filesystem] Server started and connected successfully
2026-07-22T05:03:59.967Z [Filesystem] Message from client: method="initialize" id=0
2026-07-22T05:04:00.816Z [Filesystem] Message from server: id=0 result
2026-07-22T05:04:00.816Z [Filesystem] Message from client: method="notifications/initialized"
2026-07-22T05:04:00.835Z [Filesystem] Message from client: method="tools/list" id=1
2026-07-22T05:04:00.837Z [Filesystem] Message from server: id=1 result
// nothing further

mcp.log shows the identical picture.

Consistent with @itdoor1520: a built-in MCP call (Claude in Chrome) returned a valid result in the same conversation in which every Filesystem call failed, so dispatch is not broken globally — only for the external stdio server.

Remediation attempted, none of it made any difference:

1. Connector disabled -> full app restart -> re-enabled
2. Multiple full app restarts
3. Multiple full system reboots
4. Extension uninstalled and reinstalled
5. Calls issued within seconds of a fresh handshake

The 8 clean handshakes logged today are the result of those attempts — the server comes up correctly every single time and still never receives a call.

Full logs available on request.

Confirming on a second environment, with three findings that narrow this down considerably. Full forensic writeup with logs: modelcontextprotocol/servers#4545

Environment: Windows 11 Enterprise 10.0.26200, Claude Desktop 1.24012.1 (Microsoft Store MSIX), Filesystem extension 2026.7.10, system Node v22.22.0. Identical symptom: server completes initialize + tools/list every session; zero tools/call ever arrive (last successful call in mcp-server-Filesystem.log predates the extension auto-update).

1. The regression boundary is the server's tool-schema rewrite, not roots or transport.
Inspecting @modelcontextprotocol/server-filesystem npm tarballs:

• ≤ 2025.8.21 (old tools/list shape, no outputSchema) → dispatches fine on 1.24012.1. Verified directly: temporarily swapping the 2025.8.21 dist/ into the installed extension made all 14 tools work in chat until the app's extension-integrity check reverted the registration.
• ≥ 2025.11.25 (registerTool + outputSchema/structuredContent on every tool) → client never dispatches a single call. No error surfaced beyond "Tool execution failed".
• MCP roots support (2025.7.29) is not the cause — it shipped in versions that worked for months.

2. The broken dispatch layer appears to be in the remotely-served chat code, not the native build.
Two machines on the same account: one applied the pending desktop update, one did not. Both broke identically and simultaneously when the extension registry pushed 2026.7.10 (the extension self-updates on a ~6h timer — .../dxt/extensions/ant.dir.ant.anthropic.filesystem/download/... in main.log). App version was not a variable; no local update/rollback/freeze changes the behavior.

3. Control case: a third-party registry extension using the old tool schema (Windows-MCP) lists and executes tools normally in the same chat sessions — bridge, approval gate, and dispatch all work for old-shape servers.

Also for anyone attempting workarounds — all injection paths are blocked: claude_desktop_config.json mcpServers entries connect but are never bridged into chat (+0 local-mcp); locally installed .mcpb extensions run but localMcpBridge never announces non-registry (local.mcpb.*) extensions; and modifying the installed extension's files silently kills its tool registration on the next enable/disable (only a full UI reinstall restores it).

Requests beyond the fix itself: surface an actual error instead of a bare "Tool execution failed", and version-gate registry extension pushes against client compatibility — the silent ~6h auto-update is what turned a schema change into a same-day fleet-wide outage.

OP here. I deleted my two earlier comments and am consolidating into one, partly to reduce noise and partly because one data point in them was wrong — see the retraction below.

---

Retraction first. I earlier cited "Cowork reads local files fine in the same app" as evidence for scoping the regression. That comparison does not hold and should be disregarded: Cowork reaches local files through its own mechanism (coworkUserFilesPath in claude_desktop_config.json), not through an external stdio MCP server, so it says nothing about tools/call dispatch. @itdoor1520's built-in Claude in Chrome observation is the valid comparison — same session, same Chat mode, with only the internal-vs-external-stdio variable changing.

---

@sonofsmog — Your extension-registry finding is strongly corroborated by the timestamps on my machine. From extensions-installations.json:

"version": "2026.7.10",
"installedAt": "2026-07-21T22:44:15.273Z"

And the first broken server session in mcp-server-Filesystem.log:

2026-07-21T22:44:28.007Z [Filesystem] Initializing server...

12.7 seconds after the 2026.7.10 extension landed. Every session from that point on shows a healthy initialize + tools/list and zero tools/call.

Important caveat, so this isn't over-read: on my machine the app build's first_launch_at is 2026-07-21T22:42:23Z, roughly two minutes before the extension install. Unlike your two-machine setup, my data cannot isolate app version from extension push — both changed within the same window. Your control (one machine updated, one not, both breaking simultaneously on the registry push) is the stronger evidence here; mine is only consistent with it.

I can also confirm your mcpServers finding independently. I registered the same filesystem server as a classic MCP server via mcpServers in claude_desktop_config.json, pointing at system Node v24.14.0. Both servers came up in the same session and both completed their handshake — visible in mcp.log as separate entries:

2026-07-22T00:25:03.303Z [info] [filesystem] Server started and connected successfully
2026-07-22T00:25:03.307Z [info] [Filesystem] Server started and connected successfully
2026-07-22T00:25:04.429Z [info] [filesystem] Message from client: method="tools/list" id=1
2026-07-22T00:25:04.432Z [info] [filesystem] Message from server: id=1 result
2026-07-22T00:25:05.091Z [info] [Filesystem] Message from client: method="tools/list" id=1
2026-07-22T00:25:05.094Z [info] [Filesystem] Message from server: id=1 result

Both then failed identically on every call, including list_allowed_directories (no arguments, returns only the server's own config). This matches your +0 local-mcp observation: the classic entry connects but never gets bridged to chat. Worth noting it failed for two independent reasons in my case — never bridged, and pointing at a new-schema build.

---

@softreset76 — My first broken session (2026-07-21T22:44Z) falls inside the gap between your last successful call (21 Jul 18:18 UTC) and your first broken session (22 Jul 03:47 UTC). Two machines breaking at different points inside that window fits a staged extension-registry rollout better than a single app release, which supports @sonofsmog's reading over a pure app-version cause.

On the CCD 2.1.215 → 2.1.217 hypothesis: as a workaround I installed the standalone Claude Code CLI 2.1.217, and it dispatches tools/call correctly against the same servers and folders. If 2.1.217 works standalone, the CCD bump alone is probably not sufficient to explain the regression.

---

@pof-mattfraser — Consistent with your custom-server reproduction: the failure is independent of registration method (Desktop Extension vs. classic mcpServers) and independent of which server is running. Combined with @sonofsmog's schema findings, the common factor across all our reports is new-schema tool definitions plus Chat-mode dispatch, not any particular server.

---

Current picture across reporters:

| Surface | External stdio MCP tools |
|---|---|
| Desktop — Chat mode, new-schema server (≥ 2025.11.25) | Broken — no tools/call ever dispatched |
| Desktop — Chat mode, old-schema server (≤ 2025.8.21) | Works (per @sonofsmog, reverted by integrity check) |
| Desktop — built-in MCP (Claude in Chrome) | Works |
| Claude Code CLI | Works (separate config path) |

Two secondary issues on the same build, possibly MSIX-virtualization related:

1. The "Edit configuration" button in the local MCP servers panel opens %APPDATA%\Claude\Claude, which does not exist on an MSIX install. The real config lives under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\.
2. Editing the Filesystem extension's Allowed Directories in the UI intermittently returns "Cannot connect to the extension server. Try disabling and re-enabling it", while the server process is running and healthy per the logs.

Full logs available on request.

Reproduces on macOS 26.5.2 (Desktop 1.24012.0 and 1.22209.3, classic mcpServers config, nvm node v20) — identical signature: clean handshake + tools/list, no tools/call ever dispatched. On macOS the ≤2025.8.21 fallback also fails (tools dropped at registration), unlike your Windows dist-swap result. Full details: #80094

Confirming the same bug on a classic (non-MSIX) Windows install (and see new note about Linux).

• Same log signature: server starts, completes initialize / notifications/initialized /

tools/list, then zero tools/call messages ever appear in mcp.log despite repeated
failed tool calls from multiple chats. list_allowed_directories fails too.

• Allowed directory is a WSL UNC path (\\wsl.localhost\Ubuntu\...) — failure is identical

to the local-drive case above, so not path-related.

• Running the identical npx command manually (system Node v24.16.0, same NODE_OPTIONS)

starts the server fine and it serves the path.

• Repair-reinstall of the current installer from claude.ai/download: no change.
• Cloud-execution beta toggle explicitly set to desktop: no change; fresh chats fail

identically.

Broke immediately after the latest auto-update (app also crashed once around update time).

Additional datapoint: reproduced on the Linux build as well — this does not appear
to be MSIX- or Windows-specific.

• Fresh machine (Ubuntu, Claude Desktop [version]), classic mcpServers config,

server-filesystem via npx, Node v24.18.0 (nvm).

• Identical signature: server starts, completes initialize / notifications/initialized /

tools/list, then zero tools/call entries in mcp.log; every tool invocation fails
instantly, including zero-argument list_allowed_directories.

• Target directory is a healthy read-only sshfs mount (verified serving via ls

immediately before and after failed calls).

Same account also reproduces on Windows (classic non-MSIX install, WSL UNC path
target) — details in my earlier comment. Two OSes, two install types, three path
types, same zero-tools/call dispatch failure.

Additional Windows data point: the <=2025.8.21 fallback fails here too — dropped at registration instead of at dispatch. Every published version is now broken in Chat mode on this machine, in one of two distinct ways.

Environment: Windows 11 Home 10.0.26200 · Claude Desktop 1.24012.1 (Store MSIX, Claude_1.24012.1.0_x64__pzs8sxrjxfjjc) · classic mcpServers config only (no managed extension) · system Node v24.15.0, node.exe invoked directly · @modelcontextprotocol/server-filesystem from a global npm install · two filesystem server entries + one hand-rolled custom MCP server.

Baseline matches the OP exactly. 1,791 tools/call served historically per mcp-server-*.log; last successful call 2026-07-22T04:56:39Z, on an app session running since 2026-07-21T12:03Z. The staged MSIX package folder was created 2026-07-21T22:54Z; the first relaunch after that (05:12:21Z) and every session since shows the known signature — clean initialize + tools/list, zero tools/call — surviving an npx → direct-node.exe config change, a full machine reboot, and permission re-approvals. Meanwhile the custom server (hand-rolled newline-delimited JSON-RPC, plain inputSchema, no SDK, no outputSchema) registered and dispatched normally throughout (~1,900 calls today), consistent with the schema-shape scoping already established here.

New finding. Pinned the global install to 2025.8.21 (last pre-registerTool release) to reproduce the dist-swap workaround, and restarted:

• Both filesystem servers complete initialize + tools/list normally (per their mcp-server-*.log).
• main.log shows localMcpBridge dropping them at registration — they are never announced, and their tools disappear from every surface, including Claude Code (Desktop) sessions that had been working minutes earlier:

# 16:17:00Z launch — server-filesystem 2026.7.10
[localMcpBridge] announcing mizan-code: 2 tool(s)
[localMcpBridge] announcing mizan-owned: 14 tool(s)
[localMcpBridge] announcing mizan-owned2: 14 tool(s)

# 17:03:47Z launch — server-filesystem 2025.8.21, config otherwise identical
[localMcpBridge] announcing mizan-code: 2 tool(s)
# (filesystem servers never announced; their own logs show tools/list served at 17:03:43Z)

So on this machine: <=2025.8.21 → dropped at registration (the behavior #80094 reports on macOS — now confirmed on Windows), and >=2025.11.25 → announced but never dispatched. npm has no releases between the two, so no published version currently works in Chat mode. One caveat on comparability: @sonofsmog's successful dist-swap ran inside the managed extension subsystem, while this test is the classic-config localMcpBridge path — but given their swap worked earlier the same day on the same app build, this is at least consistent with the remotely-served-chat-code reading, and it means the downgrade/dist-swap workaround is already dead for classic-config users.

Two collateral notes: (1) the same 2026.7.10 servers dispatch fine from Claude Code (Desktop) sessions on this machine — the roots-negotiating client path is unaffected; Chat mode only. (2) The global install has been reverted to 2026.7.10, since the old pin was strictly worse — it also killed the still-working Claude Code path.

(Diagnostics gathered with Claude Code on the affected machine.)

OP here. Retitled the issue — "Windows MSIX" was misleading now that @inddev (macOS), @rob-netlaces (Linux, Windows non-MSIX) and @karroush have established the scope. Also correcting my own earlier summary table, and adding a localMcpBridge data point that contradicts one finding in this thread.

---

My machine runs both registration paths simultaneously, pointing at the same server binary: the managed extension (Filesystem, 2026.7.10) and a classic mcpServers entry (filesystem) invoking that extension's own dist/index.js with system Node v24.14.0. That makes the two paths directly comparable in one process, with no cross-machine variables.

main.log (local time, UTC−4):

2026-07-21 20:25:05 [localMcpBridge] announcing filesystem: 14 tool(s)
2026-07-21 20:25:05 [localMcpBridge] announcing Filesystem: 14 tool(s)
2026-07-22 11:50:18 [localMcpBridge] announcing filesystem: 14 tool(s)
2026-07-22 11:50:18 [localMcpBridge] announcing Filesystem: 14 tool(s)

Both paths are announced, with all 14 tools each, in the same session — and neither ever receives a tools/call. The lowercase entry appears exactly when the classic config was added (2026-07-22T00:25:03Z in mcp.log), confirming the mapping. Both sets of tools are visible and selectable in Chat; invoking either fails instantly, including zero-argument list_allowed_directories.

This appears to contradict @sonofsmog's +0 local-mcp observation that classic mcpServers entries connect but are never bridged to chat. On this build they are bridged and are announced. If that finding held elsewhere, the bridging behaviour may vary by build, platform or config shape, and is probably worth separating from the dispatch failure rather than treating as the same symptom.

Net for my machine: registration and announcement complete successfully for both paths; the failure is strictly downstream, at dispatch.

---

Correcting my earlier summary table. My row claiming old-schema servers work in Chat mode is contradicted by @karroush and @inddev. There appear to be two distinct failure modes, and my data pins down the second one:

| Condition | Where it fails |
|---|---|
| <=2025.8.21 (pre-registerTool) | At registration — dropped by localMcpBridge, never announced (@karroush on Windows, #80094 on macOS) |
| >=2025.11.25 (outputSchema/structuredContent) | At dispatch — announced with full tool list, zero tools/call (confirmed here for both managed-extension and classic-config paths) |

Per @karroush, no published server-filesystem version currently works in Chat mode, so the downgrade/dist-swap workaround is dead for classic-config users.

---

On what the variable is not. @inddev reproduces on 1.22209.3 — the build @softreset76 logged as their last working one. Same version working on one machine and failing on another rules out the local app build as the variable, consistent with @sonofsmog's two-machine control.

Separately: I installed the standalone Claude Code CLI 2.1.217 as a workaround and it dispatches tools/call correctly against the same servers and folders, which argues the CCD 2.1.215 → 2.1.217 bump alone doesn't explain this.

One open question nobody has resolved. "Schema shape" no longer cleanly explains the registration-side failure: @karroush's hand-rolled server (no SDK, plain inputSchema, no outputSchema) registers and dispatches fine, and @sonofsmog's third-party old-schema extension works — yet server-filesystem 2025.8.21, also old-schema, is dropped at registration. Whatever localMcpBridge rejects looks narrower than "lacks outputSchema", possibly SDK-version-specific. Flagging as an open question, not a conclusion.

Consistent across every report here: Claude Code dispatches the same servers correctly on the same machines. The regression is confined to Chat mode's external stdio path.

Environment: Windows 10 x64, Desktop 1.24012.1 (MSIX), Filesystem extension 2026.7.10, Node v24.14.0. Full logs available on request.

Following up on "full logs available on request" — here they are, no request needed: https://gist.github.com/DFNR2026/64f866304ecbf750a7db9aa73ea2033b

Contents: complete mcp-server-Filesystem.log and mcp.log, a filtered main.log extract (localMcpBridge / UtilityProcess / version lines), extensions-installations.json, and the mcpServers config block. Sanitized (usernames, directory names, tokens); timestamps and all MCP traffic untouched.

This covers the full timeline on one machine: extension 2026.7.10 push (installedAt 2026-07-21T22:44:15Z) → first broken session 12.7s later → classic mcpServers path added → both registration paths announced by localMcpBridge with 14 tools each in the same sessions → zero tools/call on either, across every session since.

Work around here.

https://github.com/modelcontextprotocol/servers/issues/4545#issuecomment-5056557933

Adding a four-way isolation that pins the trigger to a single field: outputSchema

Same signature as the macOS report: server completes initialize and tools/list, tools appear in chat, every call fails instantly, and the per-server log shows no tools/call ever arrives. In one session I measured 0 tools/call dispatched to @modelcontextprotocol/server-filesystem against 56 to a second local stdio server in the same session.

Four-way isolation: outputSchema is necessary and sufficient

Four minimal stdio servers, differing only in whether the single tool declares outputSchema, plus a non-standard execution field as a control. Identical protocolVersion (2025-06-18), identical declared capabilities ({"tools":{"listChanged":false}}), identical tool name (ping) and inputSchema. All four verified to answer tools/call correctly when driven directly over stdio.

Counts read from %APPDATA%\Claude\logs\mcp.log:

| server | outputSchema | execution | initialize | tools/list | tools/call dispatched | result in chat |
|---|---|---|---|---|---|---|
| osx-a | YES | YES | 1 | 1 | 0 | Tool execution failed |
| osx-b | YES | no | 1 | 1 | 0 | Tool execution failed |
| osx-c | no | YES | 1 | 1 | 1 | pong |
| osx-d | no | no | 1 | 1 | 1 | pong |

• All four connect identically — initialize and tools/list succeed on every one.
• The two declaring outputSchema receive zero tools/call. The client never sends one.
• execution has no effect — osx-c carries it and works. Not a factor.
• osx-d is the control (neither field) and passes, so this is not a "newly registered servers don't work" artefact.

Repro server

Run as python osx_probe.py with (fails) or python osx_probe.py without (works).

import json, sys
WITH = len(sys.argv) > 1 and sys.argv[1] == "with"
TOOL = {"name": "ping", "description": "returns a fixed string",
        "inputSchema": {"type": "object", "properties": {}, "additionalProperties": False}}
if WITH:
    TOOL["outputSchema"] = {"$schema": "http://json-schema.org/draft-07/schema#",
        "type": "object", "properties": {"content": {"type": "string"}},
        "required": ["content"], "additionalProperties": False}
def send(o): sys.stdout.write(json.dumps(o) + "\n"); sys.stdout.flush()
while True:
    line = sys.stdin.readline()
    if not line: break
    try: m = json.loads(line)
    except Exception: continue
    meth, mid = m.get("method"), m.get("id")
    if meth == "initialize":
        send({"jsonrpc":"2.0","id":mid,"result":{"protocolVersion":"2025-06-18",
              "capabilities":{"tools":{"listChanged":False}},
              "serverInfo":{"name":"osx","version":"1.0.0"}}})
    elif meth == "tools/list":
        send({"jsonrpc":"2.0","id":mid,"result":{"tools":[TOOL]}})
    elif meth == "tools/call":
        r = {"content":[{"type":"text","text":"pong"}]}
        if WITH: r["structuredContent"] = {"content":"pong"}
        send({"jsonrpc":"2.0","id":mid,"result":r})
    elif mid is not None:
        send({"jsonrpc":"2.0","id":mid,"error":{"code":-32601,"message":"Method not found"}})

Steps: register both variants under mcpServers in claude_desktop_config.json ("args": ["<path>/osx_probe.py", "with"] and "without"), fully quit and reopen Claude Desktop (config is read only at launch), ask the model to call ping on each, then count method="tools/call" per server tag in mcp.log.

Expected: both dispatch and return pong.
Actual: without returns pong; with hangs for minutes, fails with "Tool execution failed", and shows zero tools/call in mcp.log.

Windows version boundary

• Claude Desktop 1.24012.1 (MSIX Claude_1.24012.1.0_x64) — broken.
• 1.22209.x — last good, 19 Jul 2026.
• Broke when the app auto-updated into the 1.24012.x line on 22 Jul 2026. The 1.24012.0 release notes list no MCP change.
• OS: Windows 11 Pro (build 26200).
• Affected server: @modelcontextprotocol/server-filesystem 2026.7.4 (serverInfo secure-filesystem-server 0.2.0), Node over stdio.
• Both sides negotiate protocolVersion 2025-06-18, so this is not a protocol mismatch.

Ruled out by direct testing

Full app reinstall (config intact); OS reboot and full shutdown; server-filesystem 2026.1.14 / 2026.7.10 / 2026.7.4 all fail identically; removed a duplicate bundled Filesystem connector; allowed directory confirmed correct; MCP Roots not in use ("Client does not support MCP Roots, using allowed directories set from server args"); not a capability-declaration problem (the failing server declares only tools, the working one declares more and is fine); not the execution field (isolated above).

Why this breaks so much

@modelcontextprotocol/server-filesystem declares outputSchema on all 14 of its tools, so every filesystem tool is dead. The same will apply to any server that adopts structured output. A Python FastMCP server on the same machine, declaring outputSchema on none of its tools, works normally throughout — which is currently the only reason this machine still has filesystem access at all.

The failure is never-dispatched at the transport, surfaced to the user as a multi-minute client-side timeout with no error logged anywhere.

Resolved for me by the app-1.24012.9 update; both Windows (WSL UNC target) and previously-failing setups now dispatch tools/call normally.