Repository navigation
mcp: local server process not restarted after in-place binary replacement (running code can lag disk) #55695
Description
Summary
A local MCP server process is not restarted when its binary is replaced in place. After upgrading an MCP server binary, existing sessions keep serving the old code indefinitely, while a fresh stdio run of the same binary shows the fixed behavior. The version an agent is actually talking to can silently disagree with the binary on disk, with no diagnostic surfacing the mismatch.
Context
Reproduced 2026-10-15 (OpenCode v2.0.21, linux x64, local stdio MCP server):
- A session starts the MCP server from binary v0.1.2 (buggy).
- The binary file is replaced in place at the same path with v0.2.0 (standard release update).
- Tool calls in the running session still return the old behavior;
psshows the process alive and/proc/<pid>/exepoints to the old binary with a(deleted)suffix. - Running the new binary manually (stdio smoke test) shows the fixed behavior — the on-disk code is correct, the running process is not.
- Only a new session picks up the new binary.
This made an already-fixed bug look unfixed and cost significant debugging time (the mismatch is invisible to the agent).
Related (different surfaces, both closed): #35285 (desktop keeps stale local MCP state), #53065 (MCP observability surface). This issue is the CLI/session case: the running process vs. the binary on disk.
Proposal
- Detect changes to the configured local MCP command binary (mtime + size at minimum) and restart the server process at the next tool call when it changed.
- At minimum, surface the running server's
serverInfo.version(from the MCPinitializeresult) in MCP-related diagnostics or tool errors so the mismatch is visible to the agent.
Acceptance criteria
- After replacing a local MCP binary in place, the next tool call in an existing session is served by the new binary.
- Or: a visible diagnostic reports the mismatch between the configured binary and the running process.
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed report, @PhilHem! You're asking for OpenCode to notice when a local MCP server's binary has been replaced in place and restart the server at the next tool call. Or, at least, to show the running server's
serverInfo.versionso the agent can see when the running code doesn't match the binary on disk.Right now a local stdio server is started once and only restarted after a transport error or a manual reconnect. Nothing watches the binary for changes, so this is a gap in current behavior rather than a regression. Maintainers will consider it.
Until then, you may be able to pick up a new binary without starting a new session by disconnecting and reconnecting the server from
/mcps.Related issues: