Repository navigation
v1.1.6 still has memory bloat - heap not released + MCP orphan processes #7261
Description
Environment
- OpenCode version: 1.1.6 (Jan 7, 2026)
- OS: macOS 26.0.1 (arm64, Apple Silicon)
- RAM: 64 GB
- Installation: Self-update (
~/.opencode/bin/opencode)
Problem
After updating to v1.1.6 (which was supposed to fix memory issues per #5363, #6119, #7046), experiencing:
- Session hangs during normal chat
- Memory bloat until entire machine becomes unresponsive
- Orphaned MCP server processes accumulating across sessions
Diagnostics
1. Go Heap Arena Accumulation
Actual RAM: 862 MB
Virtual: 485 GB ← abnormally high
The process accumulates Go heap arenas (128MB each) that are never released:
VM_ALLOCATE 300000000-308000000 [128.0M 6336K ...]
VM_ALLOCATE 308000000-310000000 [128.0M 0K ...]
VM_ALLOCATE 310000000-318000000 [128.0M 0K ...]
... (32+ arenas in a fresh session)
Go's GC collects objects but doesn't return memory to OS. Over long sessions with many tool invocations, this balloons to 70GB+.
2. MCP Server Process Leaks
When OpenCode exits (crash or normal), MCP servers aren't terminated:
# Found after previous session crashed:
PID 37195 - context7-mcp (started 4:13 PM) ← ORPHAN
PID 37184 - context7-mcp (started 4:13 PM) ← ORPHAN
PID 37227 - chrome-devtools-mcp (started 4:13 PM) ← ORPHAN
PID 37216 - chrome-devtools-mcp (started 4:13 PM) ← ORPHAN
# Current session spawns NEW ones:
PID 75937 - context7-mcp (started 4:28 PM)
PID 75927 - chrome-devtools-mcp (started 4:28 PM)Each crashed/exited session leaves ~300MB+ of orphan MCP processes.
3. Temp File Accumulation
27 JIT-compiled .dylib files in /private/tmp/ not cleaned up between sessions.
Reproduction
- Start OpenCode, use for 30+ minutes with various tool calls (file reads, greps, etc.)
- Exit session (or let it crash)
- Start new session
- Repeat 3-4 times
- Observe:
ps aux | grep opencodeshows multiple orphan MCP processes - Observe: System becomes sluggish, eventually unresponsive
Proposed Fixes
For Go memory retention:
// After processing large tool outputs:
runtime.GC()
debug.FreeOSMemory() // Actually returns memory to OSFor MCP orphans:
- Register cleanup handler on SIGTERM/SIGINT/SIGKILL
- Track spawned MCP PIDs and kill on exit
- Consider using process groups for clean termination
For users (workaround):
# Kill orphaned MCP servers between sessions
pkill -f "context7-mcp|chrome-devtools-mcp|atlassian-mcp"Related Issues
- opencode eating 70gb of memory? #5363 - "OpenCode eating 70GB of memory?"
- [Bug] TUI fails to render with raw ANSI output and critical memory leak (72.5G VIRT) on startup #6119 - Critical memory leak on startup (72.5GB VIRT)
- memory leak #7046 - Memory leak (v1.1.3/v1.1.4)
Notes
v1.1.6 release notes mention "tool output truncation" fix, but the underlying Go memory retention issue persists. The truncation helps reduce peak allocation, but doesn't address the arena retention problem.
Activity
rekram1-node commentedon Jan 7, 2026
Go arenas? This isn't a go codebase...
github-actions commentedon Jan 7, 2026
This issue might be a duplicate of existing issues. Please check:
These issues describe similar memory bloat and virtual memory accumulation problems. Feel free to ignore if this specific case with Go heap arenas and MCP orphan processes addresses new aspects.
mike-lsadigital commentedon Jan 7, 2026
Correction: I misidentified the runtime.
I saw 128MB VM_ALLOCATE arena patterns and incorrectly assumed Go. OpenCode is TypeScript/Bun - my apologies for the confusion.
The underlying observations still stand:
.dylibfiles accumulating in/private/tmp/The memory retention is likely Bun/V8 heap behavior rather than Go arenas. The fix suggestions for Go GC obviously don't apply - please disregard those.
The MCP orphan issue and process cleanup on exit remain valid concerns.
[-]v1.1.6 still has memory bloat - Go heap arenas not released + MCP orphan processes[/-][+]v1.1.6 still has memory bloat - heap not released + MCP orphan processes[/+]fix: force kill MCP server processes on dispose to prevent orphan pro…
Nsomnia commentedon Jan 11, 2026
I have my arch based system with oh-my-opencode hang whenever any language compile commands are make agentically—if this is related.
ryanwyler commentedon Mar 1, 2026
The orphaned MCP processes fix/workaround got merged in the latest build. The issue is the MCP SDK doesn't properly initiate the MCP processes so when the MCP SDK attempts to kill the mcp service, it hangs and eventually only kills the mcp service but the children stay orphaned. This is a problem with the MCP SDK but I put a workaround in place until the MCP SDK gets fixed.
#15516
thdxr commentedon Apr 2, 2026
Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.