core: cached locations multiply MCP subprocesses

[kitlangton]

Summary

One V2 managed service can retain a full configured MCP subprocess set for every active or cached Location. A live 0.0.0-next-15839 snapshot showed approximately ten repeated MCP process groups under one healthy service, with about five configured MCP children per group. The direct children accounted for roughly 2.2 GiB RSS even though the MCP processes were idle at the sample boundary.

This is separate from process-global event fan-out, but the costs multiply in the same many-TUI workflow: each TUI commonly owns a different Location, so one service accumulates both more Location graphs and more MCP subprocess sets over time.

Reproduction

1. Configure several local MCP servers at user scope.
2. Start one managed V2 service.
3. Open TUIs across approximately ten distinct Locations.
4. Inspect the managed service process tree after Location acquisition.
5. Leave Locations idle and verify whether their MCP subprocess groups are torn down after the configured Location cache TTL.

Expected Behavior

• Project-specific MCP declarations remain Location-isolated.
• Identical user-global MCP declarations do not require one eager subprocess per Location unless the server protocol or effective configuration requires isolation.
• MCP servers that are not used by a Location can start lazily.
• Evicting an idle Location deterministically stops every MCP subprocess owned by that Location.
• Resource use has a documented scaling model for many concurrently open Locations.

Actual Behavior

The managed service had approximately ten start-time clusters containing the same configured MCP process shapes, for approximately 50 persistent MCP children. These clusters aligned with Location acquisition rather than tool invocation. The implementation currently makes MCP a Location node and depends on Location-scoped config, integrations, forms, credentials, and events.

The service remained semantically healthy, but it was under broader runtime pressure: its health request took 1.78 seconds, and the managed server plus connected OpenCode clients accounted for about 13 GiB RSS and 457% CPU in the same snapshot. No process was restarted or terminated during measurement.

Investigation Constraints

This should not be solved by making all MCP state process-global. Effective MCP configuration, credentials, integration ownership, forms, events, and tool registration can differ by Location. The ownership key needs to reflect those semantics.

Candidate directions to measure:

• Start configured MCP servers only when tools, prompts, resources, or instructions are first requested.
• Share a process only when the complete effective declaration and credential/placement semantics are identical.
• Separate a shareable transport/process owner from Location-specific registration and event projection.
• Verify the 60-minute Location idle TTL closes MCP scopes and child processes under real TUI usage.

Acceptance Criteria

• A test opens multiple Locations with the same global MCP declaration and asserts the intended subprocess count.
• A distinct project-scoped declaration remains isolated.
• Concurrent first use shares one startup per ownership key.
• Location eviction stops unshared children and releases shared ownership without interrupting remaining Locations.
• A many-Location benchmark records child count, RSS, startup time, and teardown time.
• Diagnostics report MCP ownership and lifecycle without command arguments, credentials, paths, prompts, or tool payloads.

Related

• 2.0: Scope event streams and bound event payloads #36441 tracks process-global event delivery and oversized payload amplification.
• core: cold VCS location acquisition blocked the service for 53 seconds #37794 tracks cold Location acquisition latency.