MCP tools disappear after context compaction in long sessions (tool manifest drops to 0, server stays connected)

MCP tools disappear after context compaction in long opencode sessions

Summary

In long-running opencode sessions, after a context compaction occurs, all
MCP server tools vanish: client-side tool registration drops to zero, the
server stays connected, and only starting a new session restores the tools.

Not model-specific, not server-specific — reproducible with a local MCP
server (stdlib over stdio) and any model.

Environment

• opencode v1.18.12 (local install)
• OS: Windows (also reported/observed on other platforms in linked issues)
• MCP servers: local python -m mempalace.mcp_server (stdio transport,
  started from opencode config)
• Session: single long-running session with many tool calls → context
  compaction triggers → tools disappear

Reproduction steps

1. Configure a local stdio MCP server in opencode.json (e.g.
   python -m mempalace.mcp_server).
2. Start a new opencode session; confirm tools are available
   (opencode mcp list shows the server + tools).
3. Use the session long enough to trigger context compaction
   (auto-compaction on large context).
4. Observe after compaction:
   • opencode mcp list still shows the MCP server as connected
     (no reconnect/error state).
   • opencode debug agent build (or the equivalent tool manifest debug)
     shows 0 MCP tools in the agent's tool set.
   • Calling an MCP tool fails with "unknown tool" / tool-not-found.
5. The only reliable recovery is starting a new session.

Expected behavior

• Tool registrations from connected MCP servers survive context compaction:
  after compaction, the agent's tool manifest must be rebuilt from the still
  connected MCP server state (re-register tools), OR
• the client detects the stale/empty registration, tears down and
  transparently reconnects the MCP server, re-listing its tools.

Either way: after compaction, opencode debug agent build must show the MCP
tools again without a manual session restart.

Notes

• The MCP server process itself stays healthy (its logs show no disconnect
  during compaction).
• The bug appears to live in the client-side tool-manifest handling around
  compaction, not in the MCP servers.
• Related upstream issues: #23556, #40901, #25282.