Summary
Every ended opencode session leaves its local (stdio) MCP server child process running. The child's stdio is never closed and the process is never killed or disposed, so one ~90–110MB child accumulates per session under the long-running opencode serve --service process. After 8 sessions this was ~800MB of RSS held by idle MCP children; the memory was only reclaimed by rebooting.
Environment
- opencode version: 2.0.24
- OS: Fedora 44 (Linux 7.2.8-200.fc44.x86_64 x86_64)
- Terminal: ghostty (TERM=xterm-256color, COLORTERM=truecolor; TERM_PROGRAM=Orca when embedded)
- Shell: zsh (
/usr/bin/zsh)
Reproduction
-
Configure a local stdio MCP server, e.g.:
"mcp": {
"servers": {
"codegraph": { "type": "local", "command": ["codegraph", "serve", "--mcp"] }
}
}
-
Open the TUI and start a session; the MCP child process spawns, parented by opencode serve --service.
-
Exit the TUI / end the session.
-
The child is still running:
$ ps -eo pid,ppid,rss,etime,args | grep "serve --mcp"
One child is left behind per session, consistently (every session close).
Expected Behavior
When a session ends, its MCP client is disposed: the child's stdio pipes are closed and the child process is terminated.
Actual Behavior
The child keeps running with its stdio held open. Live evidence captured while writing this report:
opencode serve --service (up 6h41m) had 8 codegraph serve --mcp children, 88–109MB RSS each (~808MB total), elapsed times 1min–1h05m — one per session opened. Only 2 TUI client processes were alive at that moment, so at least 7 of the 8 belonged to already-ended sessions.
- 3 older children from a previous service lifetime were re-parented to
systemd --user (PPID 1525): 141MB RSS (elapsed 1d04h), 331MB, and 155MB — i.e. the children survive even the death of the service itself and keep holding memory until manually killed or the machine reboots.
Additional Context
- The observed MCP server is
codegraph serve --mcp (Node.js stdio server), but the leak looks like it is in opencode's disposal of local MCP children rather than server-specific behavior. Only one local MCP was enabled; remote MCP servers have no child process and are presumably unaffected.
- Frequency: 100% of session closes.
- Workaround: none found so far — memory growth was only stopped by rebooting.
Summary
Every ended opencode session leaves its local (stdio) MCP server child process running. The child's stdio is never closed and the process is never killed or disposed, so one ~90–110MB child accumulates per session under the long-running
opencode serve --serviceprocess. After 8 sessions this was ~800MB of RSS held by idle MCP children; the memory was only reclaimed by rebooting.Environment
/usr/bin/zsh)Reproduction
Configure a local stdio MCP server, e.g.:
Open the TUI and start a session; the MCP child process spawns, parented by
opencode serve --service.Exit the TUI / end the session.
The child is still running:
One child is left behind per session, consistently (every session close).
Expected Behavior
When a session ends, its MCP client is disposed: the child's stdio pipes are closed and the child process is terminated.
Actual Behavior
The child keeps running with its stdio held open. Live evidence captured while writing this report:
opencode serve --service(up 6h41m) had 8codegraph serve --mcpchildren, 88–109MB RSS each (~808MB total), elapsed times 1min–1h05m — one per session opened. Only 2 TUI client processes were alive at that moment, so at least 7 of the 8 belonged to already-ended sessions.systemd --user(PPID 1525): 141MB RSS (elapsed 1d04h), 331MB, and 155MB — i.e. the children survive even the death of the service itself and keep holding memory until manually killed or the machine reboots.Additional Context
codegraph serve --mcp(Node.js stdio server), but the leak looks like it is in opencode's disposal of local MCP children rather than server-specific behavior. Only one local MCP was enabled; remote MCP servers have no child process and are presumably unaffected.