Repository navigation
Memory leak #9385
Description
Description
Logically speaking, a 16GB Mac shouldn't have its memory randomly wiped out. It shouldn't be happening all the time.
Error: Unknown error
ud@tauri://localhost/assets/index-D9T6R7qf.js:2:11977
@tauri://localhost/assets/index-D9T6R7qf.js:2:4664
────────────────────────────────────────
Caused by:
{}
Plugins
oo-my-opencode
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
taxilian commentedon Jan 19, 2026
This ticket is very light on details, but I can confirm I've been seeing issues with memory growing out of bounds quite a bit myself.
I often run opencode in a coder workspace running on my kubernetes cluster; if the pod allocates more memory than is available it will be killed. I currently have that pod set to 32GB of ram because 16GB always got killed and it still eventually gets there.
I'm not 100% sure where all the issues are, but here are my thoughts / observations:
kov commentedon Jan 20, 2026
Could you give it a try with #9693 applied?
rekram1-node commentedon Jan 20, 2026
Latest release also shipped some memory fixes
censey commentedon Jan 21, 2026
testing with 1.1.27 and still massive memory consumption as it runs high models. I am actually noticing an increase in consumption rate using Opus high vs 1.1.25
rekram1-node commentedon Jan 21, 2026
Probably just the same memory issue from before, no significant changes were made that could be increasing it and a dumb bug was fixed that definitely was causing at least some of it prior
feat(desktop): add hardware acceleration toggle for Windows
relsunkaev commentedon Jan 29, 2026
Can confirm.
leeweisern commentedon Feb 6, 2026
using opencode overtime spins up multiple opencode processes that i have to kill occasionally
cloudwaddie-agent commentedon Feb 22, 2026
Investigation Complete - Memory Leak Fix
I've completed a comprehensive search for memory leaks and created a PR with fixes:
PR Created
#14635
Memory Leaks Found & Fixed
The primary cause of memory leaks was event listeners not being cleaned up when TUI components unmount:
app.tsx - 6 SDK event listeners fixed:
TuiEvent.CommandExecuteTuiEvent.ToastShowTuiEvent.SessionSelectSessionApi.Event.DeletedSessionApi.Event.ErrorInstallation.Event.UpdateAvailablesession/index.tsx - 1 event listener fixed:
message.part.updatedprompt/index.tsx - 1 event listener fixed:
TuiEvent.PromptAppendWhy This Causes Memory Issues
Previously, these listeners were registered in component render but never unregistered. When components remount (switching sessions, navigating), duplicate listeners accumulate without being cleaned up, causing memory to grow continuously, leading to the 98% memory usage you reported.
How to Test
cd packages/opencode && bun run buildhtopor Activity MonitorOr use heap snapshots via
opencode.statuscommand.kryptobaseddev commentedon Feb 22, 2026
I've been investigating this and put together a fix in #14650 that addresses the subagent deallocation problem specifically called out here, plus several other leak sources.
The biggest finding: when the
tasktool creates a subagent session viaSession.create()intool/task.ts, that session is never cleaned up after the task completes. Each subagent retains its full message history, tool output buffers, and event listeners in memory indefinitely. The more subagents you use, the faster memory grows — which matches what @leeweisern showed with multiple opencode processes accumulating.The fix calls
Session.remove()after extracting the task result. The event-reducer already hadcleanupSessionCaches()wired up tosession.deletedevents — it just was never triggered for subagent sessions. So the cleanup infrastructure existed, it just needed to be invoked.The PR also includes the same TUI listener cleanup that #14635 addressed (which was closed), plus fixes for 8 other leak sources across the codebase — SSE buffer overflow, MCP OAuth transport leaks, LSP diagnostics growth, tool output surviving compaction, pending permissions not cleared on session delete, and unbounded delta string accumulation in the event-reducer.
Tested by building a standalone binary and running it for 2.5 hours with continuous subagent tasks and session switching. RSS stabilized at ~2,500 MB after initial loading and held flat — previous behavior would climb toward 25+ GB under the same workload. Full monitoring data is in the PR description.
n0one42 commentedon Feb 23, 2026
Okay... It seems like I need a farm of my MacBook Pro M4 Max to run OpenCode ;)
OpenCode GUI
thdxr commentedon Apr 2, 2026
Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.