Bug: Shared OpenCode host keeps per-directory MCP child processes alive on Windows after switching routed directories/worktrees

[VooDisss]

Description

On Windows, a shared OpenCode host does not clean up old MCP child processes when switching between routed directories/worktrees.

After using MCP in directory A and then directory B, I still see both mcp-server.exe processes alive under one opencode.exe, even after mcp.disconnect(...) or instance.dispose() for the previous directory. This keeps the executable locked and blocks rebuilds.

Steps to reproduce

1. Start one shared OpenCode host.
2. Use MCP in directory A.
3. Switch to directory B and use MCP there.
4. Dispose or disconnect the previous directory instance.
5. Check running processes.

Expected behavior

The old MCP child exits.

Actual behavior

The old MCP child stays alive.

Notes

The host itself is not exiting here. I attached a markdown file with more detailed investigation.

opencode-shared-host-mcp-lifecycle-issue.md - more context for your agents inside.

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The description appears to be AI-generated — it is an extremely long wall of text with extensive structured sections (lifecycle sketches, upstream evidence lists, root cause hypotheses, risk/caution sections, test plans, etc.). AI-generated walls of text are not acceptable per our contributing guidelines. Please rewrite the issue in your own words, concisely describing the bug, how to reproduce it, and what you observed.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• TUI: signal exits leak child processes #14237: TUI signal exits leak child processes — related issue about child processes not being cleaned up on exit
• [FEATURE]: opencode serve should propagate SIGTERM to its child processes #20899: opencode serve should propagate SIGTERM to its child processes — related issue about orphaned child processes accumulating under the opencode host

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for updating the issue! It now follows the contributing guidelines and includes all the necessary information. We appreciate the detailed reproduction steps and the additional context. Your report has been reviewed and the compliance flag has been removed.

[VooDisss]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The description appears to be AI-generated — it is an extremely long wall of text with extensive structured sections (lifecycle sketches, upstream evidence lists, root cause hypotheses, risk/caution sections, test plans, etc.). AI-generated walls of text are not acceptable per our contributing guidelines. Please rewrite the issue in your own words, concisely describing the bug, how to reproduce it, and what you observed.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

This issue might be a duplicate of existing issues. Please check:

• TUI: signal exits leak child processes #14237: TUI signal exits leak child processes — related issue about child processes not being cleaned up on exit
• [FEATURE]: opencode serve should propagate SIGTERM to its child processes #20899: opencode serve should propagate SIGTERM to its child processes — related issue about orphaned child processes accumulating under the opencode host

If you believe this was flagged incorrectly, please let a maintainer know.

The linked issues are related because they are all child-process cleanup/lifecycle problems, but they do not appear to be duplicates. Those issues are about cleanup on host/process exit, while this issue is about per-directory MCP cleanup failing inside a still-running shared host on Windows.