anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:43:39 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 17:43:39 -05:00
Owner
Copy Link
Copy Source

Originally created by @mike-lsadigital on GitHub (Jan 7, 2026).

Originally assigned to: @rekram1-node on GitHub.

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.

Originally created by @mike-lsadigital on GitHub (Jan 7, 2026). Originally assigned to: @rekram1-node on GitHub. ## 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: ```bash # 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: ```go // 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): ```bash # 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.
yindo added the perf label 2026-02-16 17:43:39 -05:00
yindo commented 2026-02-16 17:43:39 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 7, 2026):

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

@rekram1-node commented on GitHub (Jan 7, 2026): Go arenas? This isn't a go codebase...
yindo commented 2026-02-16 17:43:40 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 7, 2026):

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.

@github-actions[bot] commented on GitHub (Jan 7, 2026): 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.
yindo commented 2026-02-16 17:43:40 -05:00
Author
Owner
Copy Link
Copy Source

@mike-lsadigital commented on GitHub (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:

  • 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.

@mike-lsadigital commented on GitHub (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: - **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.
yindo commented 2026-02-16 17:43:40 -05:00
Author
Owner
Copy Link
Copy Source

@Nsomnia commented on GitHub (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.

@Nsomnia commented on GitHub (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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label perf
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4393
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?