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.

[rekram1-node]

Go arenas? This isn't a go codebase...

[github-actions[bot]]

This issue might be a duplicate of existing issues. Please check:

• #5363: opencode eating 70gb of memory?
• #6119: Critical memory leak on startup (72.5G VIRT) on Debian
• #7046: memory leak on Windows

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]

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:

• 485GB virtual address space in a session
• MCP server processes not cleaned up on exit (orphans accumulate)
• Temp .dylib files 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.

[Nsomnia]

I have my arch based system with oh-my-opencode hang whenever any language compile commands are make agentically—if this is related.