Context compaction drops MCP tool registrations #40901
Description
Bug Report: MCP tools dropped after context compaction
Bug Description
MCP server tools (e.g., outline_list_collections, outline_list_documents) are available as native tools in fresh sessions but get dropped after context compaction occurs during a long conversation.
Steps to Reproduce
- Configure an MCP server (e.g., Outline wiki MCP) in
opencode.json - Start a new session and use an MCP tool — works ✅
- Have a long conversation that triggers context compaction (the "Your operational mode has changed from plan to build" message)
- Try to use the same MCP tool — fails ❌ with "Model tried to call unavailable tool"
Expected Behavior
MCP tool registrations should persist across context compactions. The MCP server connection persists (opencode mcp list still shows it as connected), but the tool bindings are lost.
Actual Behavior
After context compaction:
opencode mcp listshows the MCP server is still connectedopencode debug agent buildshows 0 MCP tools registered- Fresh sessions correctly register MCP tools
Evidence
Fresh session test:
opencode run "List all collections from Outline wiki"
> outline_list_collections → ✅ Works
Same session after compaction:
opencode debug agent build
> tools: [...no outline tools...]
Environment
- OpenCode version: 1.18.10
- OS: macOS (Darwin 25.5.0 arm64)
- MCP server: Outline wiki (remote via mcp-remote proxy)
Impact
MCP tools become unusable mid-conversation, forcing users to either:
- Start a new session
- Use curl to call the MCP server directly (bypassing opencode integration)
Additional Context
The MCP server remains connected throughout the session (opencode mcp list shows it as connected), but the tool registrations are lost during context compaction. This suggests the issue is in how opencode manages tool state during context compression, not in the MCP server connection itself.
Verified with:
opencode mcp list→ shows server connectedopencode debug agent build→ shows 0 MCP tools registered- Fresh session → MCP tools work correctly
Model Independence Testing
This bug is NOT model-specific. Tested across 7 different models with consistent results:
| Model | Fresh Session | After Context Fill |
|---|---|---|
| opencode/mimo-v2.5-free | ✅ Works | ❌ Dropped |
| opencode/deepseek-v4-flash-free | ✅ Works | ❌ Dropped |
| opencode/laguna-s-2.1-free | ✅ Works | ⏱️ Timeout (web fetch) |
| opencode/longcat-2.0-free | ✅ Works | ❌ Dropped |
| opencode/nemotron-3-ultra-free | ✅ Works | ❌ Dropped |
| opencode/north-mini-code-free | ⏱️ Timeout | Not tested |
| opencode/big-pickle | ✅ Works | Not tested |
Conclusion: The bug occurs regardless of which model is being used. This confirms it is a general opencode issue with MCP tool state management during context compaction, not a model-specific problem.
Activity
opencode-agent commentedon Aug 6, 2026
Thanks for the detailed report. We reviewed this against v1.18.10 and the current
devbranch, but the evidence here does not indicate that context compaction is dropping MCP tool registrations.The message
Your operational mode has changed from plan to buildis emitted when the session switches from theplanagent to thebuildagent; it is not a context-compaction message.Also,
opencode debug agent buildreports the agent’s statically registered tools and their resolved permissions. It does not enumerate the MCP tools dynamically attached to a normal model request, so MCP tools being absent from that command’s output is expected and does not show that their registrations were lost. Normal session steps resolve connected MCP tools separately when constructing the request.We’re closing this as not reproduced based on the current evidence. If the failure can be reproduced using an explicit compaction while remaining on the same agent, please open a new report with debug logs showing the MCP
listToolsresult and the subsequent model request. That would let us distinguish an MCP server/proxy failure from tool filtering or request construction.