v1.1.6 still has memory bloat - heap not released + MCP orphan processes

[mike-lsadigital]

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:

1. Session hangs during normal chat
2. Memory bloat until entire machine becomes unresponsive
3. 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

1. Start OpenCode, use for 30+ minutes with various tool calls (file reads, greps, etc.)
2. Exit session (or let it crash)
3. Start new session
4. Repeat 3-4 times
5. Observe: ps aux | grep opencode shows multiple orphan MCP processes
6. 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 OS

For 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

• #5363 - "OpenCode eating 70GB of memory?"
• #6119 - Critical memory leak on startup (72.5GB VIRT)
• #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.