Skip to content

opencode serve: local stdio MCP connection silently dropped mid-session — tools become permanently unavailable #38266

Closed as not planned

Description

@Ron-RONZZ-org

Summary

Local stdio MCP servers (specifically serena-agent) work initially in opencode serve + opencode attach mode, but silently lose their connection after some tool calls. The MCP server process stays alive, no error is logged in the MCP server's logs — the tool execution itself completes in <20ms — but the opencode server-side MCP client has already dropped the connection, causing subsequent tool calls to time out.

Reproduction

  1. Start opencode in serve mode: opencode serve --port 4096
  2. Attach a session: opencode attach http://127.0.0.1:4096
  3. Verify serena MCP server is configured and appears connected
  4. Use serena_create_text_file or other serena tools successfully (they work)
  5. After some period or number of tool calls, serena tools become unavailable
  6. The serena process remains running (ps aux shows the process alive with same PID)
  7. The user sees: Model tried to call unavailable tool 'serena_create_text_file' or tool calls time out
  8. The serena MCP logs (~/.serena/logs/) show the tool completed successfully with zero errors

Evidence

  • serena-side: All create_text_file calls complete in <20ms. Zero timeout errors in serena logs across all sessions.
  • Process state: Multiple serena processes remain running (ps aux | grep serena) — they never crashed.
  • Tool availability: serena tools ARE available at session start (initial serena_read_file, serena_get_symbols_overview calls succeed), then BECOME unavailable later.
  • No serena-side error: The disconnect is invisible to serena — it never knows the client dropped the connection.
# serena log showing successful execution:
INFO  2026-07-22 08:44:58,683 [MainThread] mcp.server.lowlevel.server:_handle_request - Processing request of type CallToolRequest
INFO  2026-07-22 08:44:58,724 [SerenaAgentTaskExecutor] serena.task_executor:_process_task_queue - Starting execution of Task-44:CreateTextFileTool
INFO  2026-07-22 08:44:58,728 [Task-44:CreateTextFileTool] serena.tools.tools_base:task - Result: File created: tests/test_doi_routes.py.
INFO  2026-07-22 08:44:58,729 [Task-44:CreateTextFileTool] serena.task_executor:stop - Task-44:CreateTextFileTool completed in 0.004 seconds

Root Cause Analysis

The serena MCP tool execution itself is fast (<20ms) and never errors. The problem is at the opencode server's MCP transport layer in serve mode:

  1. The opencode serve daemon spawns a serena process per session and communicates via stdio
  2. The MCP client (in packages/opencode/src/mcp/index.ts) calls client.listTools() on every LLM step via resolveTools() (as documented in Bug: MCP tools permanently lost mid-session after single transient listTools() failure — no retry, no reconnect #17099)
  3. A transient listTools() failure (e.g., pipe hiccup, GC pause, timing issue) triggers the catch handler which permanently deletes the MCP client from state.clients
  4. Once deleted, the client is never recreated — the serena process stays alive but the opencode server has no reference to it
  5. In opencode serve mode, this eviction affects ALL attached sessions (they share the server's MCP state)
  6. The timeout field in McpLocalConfig only covers the initial handshake, not ongoing per-request calls

The --project-from-cwd flag also means each serena process independently auto-detects the project and starts LSP servers, which adds startup time that makes the initial listTools() more likely to hit timeouts.

Related Issues

Environment

  • opencode version: 1.18.4
  • Mode: opencode serve on port 4096 + opencode attach
  • MCP server: serena-agent 1.2.0 (Python FastMCP, stdio transport)
  • OS: Linux (Debian)

Activity

  1. wdz211 commented on Aug 4, 2026

    @wdz211

    Additional Windows reproduction evidence (OpenCode Desktop 1.18.13, Windows 11, local stdio MCP):

    • Configured multiple local MCP servers in the user-level opencode.json, including desktop-touch.
    • After starting OpenCode Desktop, the same MCP entries were spawned twice under the same OpenCode utility process. This was reproducible for multiple servers, not only desktop-touch (playwright, filesystem, github, and deepwiki also appeared twice).
    • desktop-touch then became unresponsive: server_status and desktop_state returned MCP error -32001: Request timed out; the child process remained alive and loaded the native Windows UIA engine. Diagnostic output showed CPU spikes and a slow desktop_state call rather than a clean child-process crash.
    • Restarting OpenCode temporarily restored the connection, but the duplicate MCP spawn recurred.
    • A local singleton wrapper around the stdio command prevented the second desktop-touch child from loading the native engine. With that workaround, terminal reads succeeded, which isolates the failure to the OpenCode MCP lifecycle/transport layer rather than the MCP server's native module.

    This appears related to the issue's described class of failures: the MCP child remains alive while the OpenCode-side client/transport becomes unusable and requests time out. The duplicate local-server spawning is an additional Windows Desktop symptom worth investigating. Suggested diagnostics: log MCP server key, client instance identity, spawn/close/reconnect events, and ensure reconnect/disposal is idempotent when the same config is initialized more than once.

  2. github-actions commented on Oct 5, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions