Memory leak #9151

Activity

1. amat27

   added

   bugSomething isn't workingSomething isn't working

   on Jan 17, 2026
2. github-actions

   assigned

   rekram1-node

   on Jan 17, 2026
3. github-actions

   added

   perfIndicates a performance issue or need for optimizationIndicates a performance issue or need for optimization

   windows

   on Jan 17, 2026
4. github-actions commented on Jan 17, 2026

   

   github-actionsbot

   on Jan 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • memory leak #7046: memory leak
   • Too high memory usage #5700: Too high memory usage
   • opencode eating 70gb of memory? #5363: opencode eating 70gb of memory?

   Feel free to ignore if none of these address your specific case.
5. LIHUA919 commented on Jan 18, 2026

   

   LIHUA919

   on Jan 18, 2026

   More actions

   Based on my analysis of the recent memory leak fixes, here are the root causes:

   Root Causes

   1. TUI Footer Timeout Leak (#8255)

   The footer component creates recursive timeouts but only cleans up the last one:

   // Before (leak):
   let timeout = setTimeout(() => tick(), 10000)
   onCleanup(() => clearTimeout(timeout))  // Only clears last timeout
   
   // After (fixed):
   const timeouts = []
   timeouts.push(setTimeout(() => tick(), 10000))
   onCleanup(() => timeouts.forEach(clearTimeout))  // Clears all

   Hundreds of uncleaned timers accumulate over time.

   2. MCP Client Not Closed (#8253)

   When reinitializing MCP clients, the old one was overwritten without closing:

   // Before (leak):
   s.clients[name] = result.mcpClient  // Old client still active!
   
   // After (fixed):
   await existingClient?.close()
   s.clients[name] = result.mcpClient

   This is especially critical for Copilot users since it uses the MCP protocol.

   3. State Instance Not Removed from Map (#8252)

   // Before (leak):
   entries.clear()  // But recordsByKey still holds reference
   
   // After (fixed):
   entries.clear()
   recordsByKey.delete(key)  // Actually remove the reference

   Common Pattern

   All three issues stem from the same problem: creating new resources without properly tracking/cleaning up old ones.

   Recommendation

   1. Update to the latest version - These fixes are very recent (merged Jan 13-14)
   2. If the issue persists, please export your session to help identify remaining leaks:

      opencode export > session.json

   3. The MCP client leak (fix(mcp): close existing client before reassignment to prevent leaks #8253) is particularly relevant for Copilot users - make sure you have this fix

   Related Fixes

   • fix(tui): track all timeouts in Footer to prevent memory leak #8255: TUI timeout leak
   • fix(mcp): close existing client before reassignment to prevent leaks #8253: MCP client leak
   • fix(state): delete key from recordsByKey on instance disposal #8252: State disposal leak
   • Fix: High CPU / memory leak when filtering model list window to empty results #6435: Model list filter leak
   • fix(plugin): prevent duplicate plugin function initialization #6787: Plugin duplicate initialization

   👍React with 👍1Reacted by Zihao Chen
6. cristian1991

   added a commit that references this issue on Jan 24, 2026

   feat(desktop): add hardware acceleration toggle for Windows

   ...

   1491dc5
7. kryptobaseddev commented on Feb 22, 2026

   

   kryptobaseddev

   on Feb 22, 2026

   More actions

   The 30 GB growth after a morning of coding matches what I found in the event-reducer. The message.part.delta handler in event-reducer.ts concatenates every incoming delta to a string per part field with no size limit — (existing ?? "") + props.delta. In a long session with lots of tool output, these strings grow into the hundreds of MB each and are never trimmed.

   Fixed in #14650 by capping each part field at 1 MB (drops oldest bytes on overflow). The PR also fixes the second major driver: subagent sessions are never deallocated after their task completes, so each one retains its full message history, tool buffers, and event listeners in memory permanently.

   Between those two fixes plus 8 other leak sources addressed in the same PR, a 2.5-hour test session with continuous subagent and tool activity stabilized at ~2,500 MB RSS instead of growing unbounded.

   Some of the leaks from this issue were fixed in v1.2.10 (footer timeout, SSE reconnect, AbortController), but the delta accumulation and subagent cleanup were still open on the current dev branch.
8. g4challenge commented on Feb 24, 2026

   

   g4challenge

   on Feb 24, 2026

   More actions

   same behavior on my mac - especially when using long web sessions - up to 68gb ram usage. session ran 2 days.
9. thdxr commented on Apr 2, 2026

   

   thdxr

   on Apr 2, 2026

   Member

   More actions

   Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.
10. thdxr

    closed this as completedon Apr 2, 2026