Upgrade MCP consumes 10–12 GB RAM and >100% CPU after running for 21 hours

Summary

The .NET process hosting Microsoft.GitHubCopilot.Upgrade.Mcp.dll remained active for more than 21 hours and grew to approximately 10.7–12 GB RSS while continuously using more than one CPU core (roughly 105–129% CPU on macOS).

Terminating the Upgrade MCP processes immediately released about 10.7 GB of memory. No project process was responsible for this usage.

Environment

• OS: macOS 15.7.7 (24G720), Intel x86_64
• Physical memory: 96 GB
• VS Code: 1.134.0 (110a328ea54b42367b803ec53ee0bf52ef26b419)
• Extension: ms-dotnettools.upgrade-agent 1.1.404 (preview)
• MCP package: Microsoft.GitHubCopilot.Upgrade.Mcp 1.1.441
• MCP package commit metadata: 6ba34b3cd8108062a680c1e362288b24fc45f81b
• .NET SDK/runtime host: 10.0.302

Steps to reproduce

This was observed during normal use rather than from a minimal deterministic reproduction:

1. Install and enable GitHub Copilot Upgrade (ms-dotnettools.upgrade-agent).
2. Use the Upgrade agent/MCP from VS Code.
3. Leave VS Code running after the upgrade interaction.
4. Monitor child dotnet processes over time, for example:

ps -axo pid,ppid,%cpu,%mem,rss,etime,command | grep '[d]otnet'

5. Observe the process whose command contains Microsoft.GitHubCopilot.Upgrade.Mcp.dll.

Actual behavior

After more than 21 hours, the Upgrade MCP process was still active and showed:

• RSS: approximately 10.7–12 GB
• CPU: approximately 105–129%
• Elapsed time: more than 21 hours

The process did not return to an idle, bounded-memory state. A small launcher/parent process and the high-memory child also required termination; one zero-RSS zombie remained until its VS Code parent exits.

Expected behavior

The MCP process should either terminate after the interaction/session ends or remain idle with bounded memory and negligible CPU usage. Long-lived sessions should not cause unbounded memory growth or sustained CPU use.

Recovery

Sending TERM did not fully remove both entries, so they were ultimately stopped with KILL. Approximately 10.7 GB was released immediately, and macOS then reported roughly 49 GB available with no active .NET process remaining.

Impact

This can silently consume a large part of system memory and a full CPU core during long-running VS Code sessions, causing system-wide memory pressure and degraded performance.