Resumed session fails every request with 400 "Tool reference '...' not found in available tools" after an MCP server's tools change between launches #5359

Describe the bug

After a resume, every request in a session failed with:

Execution failed: 400 Tool reference 'kusto-<tool>' not found in available tools

(Tool name redacted. It was one of the two tools that an earlier tool search in the same session had returned.)

This included compaction. The session stayed unusable until we changed the MCP configuration. It failed on every request: we resumed it twice, about 21 minutes apart, and both resumes failed the same way.

What happened: early in the session, deferred-tool search returned tool_reference blocks for two tools of an MCP server named kusto. Those blocks stayed in the conversation history. Later, the session shut down while idle. When it was resumed, the server name kusto resolved to a different implementation that exposes different tool names. The engine still sends the historical tool_reference blocks. They now name tools that are not in the request's tool list, so the API rejects every request, including compaction, which sends the same history.

Extensions/plugins: not tested with plugins disabled. MCP configuration is the trigger: restoring the original server, with no other change, fixed the session.

Affected version

copilot-sdk-runtime-1.0.102-0.unstable (engine bundled with the GitHub Copilot desktop app 1.1.35, Windows)

Not yet retested on 1.0.105 or 1.0.106-x.

Steps to reproduce the behavior

These steps are reduced from the failure we observed. We have not run them in isolation.

1. Configure an MCP server named foo that exposes a tool alpha, with deferred tools or tool search active.
2. In a session, have the model find alpha through tool search, so a tool_reference for foo-alpha enters the history.
3. Exit the session. Change the configuration so that the server named foo now exposes only beta. In our case, a workspace .mcp.json defining a server with the same name took precedence over the user-level definition. We expect any change that removes alpha to have the same effect.
4. Resume the session and send any prompt.
   • Every prompt returns 400 Tool reference 'foo-alpha' not found in available tools.
   • /compact fails with the same error.

Expected behavior

A tool that no longer exists should not permanently break a resumed session. Any of these would fix it:

• On resume, and before compaction, re-validate historical tool_reference blocks against the current tool list and drop the ones that no longer resolve.
• Turn stale references into plain text, for example "tool foo-alpha was available earlier in this session but is no longer configured".
• At minimum, show one clear error that names the missing server and tool and says how to recover, instead of failing every turn.

Additional context

Impact: the session is unusable. No prompt succeeds and compaction fails, so the session cannot recover by itself. Nothing in the UI points at MCP configuration as the cause. The only recovery is a configuration change.

Workaround (verified): make the server name resolve to the original implementation again. We redefined the original server under the same name in the workspace .mcp.json. The session then resumed and completed turns normally. To prevent a recurrence, give servers that could shadow each other distinct names.

How this differs from #4663: #4663 reports the same error string on the compaction path while the referenced tool still exists. It reportedly stopped reproducing on 1.0.82, and its suggested workaround is to resume the session. Here, the tool no longer exists after resume. Resuming is the trigger, not the fix, and every request fails, not only compaction. The backoff and error-surfacing that #4663 asks for would make this failure visible, but would not fix it. Also related: #4519 (closed), another 400 from replaying deferred-tool history.

Suggested labels: area:sessions, area:mcp, area:tools. We can't apply labels as an outside contributor.

Environment (collected by script; an unrelated crash section was trimmed):

App version         1.1.35
OS                  Windows 10 Enterprise 26H2 (build 26300.9711)
Architecture        AMD64
WebView2 runtime    156.0.4314.58
Copilot CLI         copilot-sdk-runtime-1.0.102-0.unstable.r41779900948.gf482387

Desktop app on Windows, git-worktree project session. No terminal emulator or shell is involved.