Multiple memory leaks cause unbounded RAM growth during extended TUI usage

[binarydoubling]

Description

During extended usage, OpenCode exhibits unbounded memory growth from multiple independent sources. This has been independently reported and investigated by 20+ contributors, resulting in a massive wave of PRs that collectively address the full scope of the problem.

Scope of Memory Leaks

In-Memory Leaks (Runtime)

Category	Source	Impact	PR(s)
TUI event listeners	sdk.event.on() in app.tsx, session route, prompt — never unsubscribed	Listeners accumulate on every navigation/re-render	#16695, #8254, #9147
Unbounded Maps/Sets	LSP diagnostics, Bus subscriptions, RPC listeners — grow without eviction	Monotonic memory growth over session lifetime	#16695, #12259
Timer/interval leaks	Models refresh interval, leader timeout, state disposal timeout — never cleared	Closures + captured state retained indefinitely	#16695, #9148
Session data retention	Sync store never frees previous session's messages/parts/diffs on switch	Memory scales with number of sessions visited	#16695, #10392
Plugin subscriber stacking	Bus.subscribeAll() called without storing unsubscribe handle	Each init() stacks another permanent wildcard subscriber	#16346
Message array retention	Full msgs array stays alive during processor.process()	Large arrays pinned in memory unnecessarily	#16346
Subagent deallocation	Subagent sessions never deallocated after task completion	GB-scale growth in long-running sessions	#14650, #15435
Event-reducer accumulation	Message delta strings accumulate without cap	Unbounded string growth	#14650
SSE stream leaks	SSE connections not properly cleaned up on disconnect	Stale connections hold memory	#15646, #9146
Process/Bus cleanup	Child processes and Bus subscriptions not cleaned on instance disposal	Resources retained after they're needed	#15646, #13186, #9149
Subscription disposal	No dispose functions for Bus subscriptions	Permanent listeners on long-lived instances	#7914, #7032
Tool output retention	Tool output and attachments not cleared when pruning	Dead data accumulates	#7049
OAuth transport leaks	MCP OAuth transports accumulate without timeout	Abandoned flows hold memory	#9145
LSP stderr buffering	LSP server stderr not consumed, grows unbounded	Memory growth per LSP server	#16241
Zombie processes	Missing cleanup handlers leave child processes running	Process accumulation over time	#13186, #15757
MCP server accumulation	Idle MCP server instances never disposed	Process count grows indefinitely	#15326
Instance disposal	No idle-timeout disposal in serve mode	Instances live forever	#16616

Database & Storage Leaks

Category	Source	Impact	PR(s)
No data retention	Sessions spanning 53+ days, never auto-cleaned	DB grew to 1.99 GB	#16730
auto_vacuum = OFF	Deleted data never reclaims disk space	SQLite file only grows	#16730
Unbounded WAL	No periodic WAL checkpoint	WAL file grows indefinitely	#16730
Oversized cache_size	64 MB fixed allocation	Excessive for embedded tool	#16730
Startup cleanup	No maintenance/cleanup on startup	Stale data persists across restarts	#16628

Real-World Impact

• 1.76 GB total memory (602 MB RSS + 1.15 GB swap) on 8 GB system (High memory usage and database bloat in long-running OpenCode instances #16729)
• 2.3 GB/min virtual memory growth rate during active usage (fix(opencode): unbounded memory growth during active usage #16346)
• 1.99 GB SQLite database with no automatic cleanup (High memory usage and database bloat in long-running OpenCode instances #16729)
• Multiple users reporting system crashes from memory exhaustion (Memory leak #9385, memory leak #7046, Memory leak: Unbounded caches grow without limit #9140, 🐛 Issue: opencode memory usage keeps growing over time #11399)

All Related PRs

Over 20 open PRs addressing memory leaks, spanning January–March 2026:

Core memory leak fixes

PR	Author	Focus	Files
#16695	@binarydoubling	TUI listeners, Maps/Sets eviction, timers, session cleanup	16
#16730	@BYK	SQLite config, database bloat, data retention	—
#16346	@GooseG17	Plugin subscriber stacking, msgs retention, LSP	5
#14650	@kryptobaseddev	Subagent deallocation, event-reducer caps	14
#15646	@brendandebeasi	SSE streams, Bus disposal, process cleanup	11
#15435	@tda1017	Consolidation of #14650 and #8953	24
#13594	@feelsodev	6 memory leaks for long-running sessions	6
#13186	@dzianisv	Memory leaks and zombie processes	16
#10392	@ztripez	Session handling memory leaks	15
#13514	@sebishogun	Multiple memory leaks (with Windows test fixes)	1

Targeted fixes

PR	Author	Focus	Files
#16616	@sjawhar	Idle-timeout Instance disposal for serve mode	2
#16241	@dimaosipa	LSP stderr unbounded growth	2
#16628	@jmylchreest	Startup cleanup and maintenance system	6
#15326	@lytedev	Dispose idle MCP server instances	2
#12259	@Stranmor	TTL, LRU eviction, ring buffers	4
#9146	@sauerdaniel	Session event stream leaks (ACP)	2
#9147	@sauerdaniel	Event listener leaks in TUI	3
#9148	@sauerdaniel	Timeout, interval, subscription cleanup	3
#9145	@sauerdaniel	OAuth transport and process cleanup	2
#9149	@sauerdaniel	Instance disposal chain for plugins/caches	6
#8254	@sauerdaniel	SDK event listener cleanup on unmount	1
#7914	@hendem	Subscription disposal functions	10
#7049	@hendem	Tool output/attachment cleanup on prune	2

Monitoring & diagnostics

PR	Author	Focus	Files
#13194	@goniz	Memory usage monitoring/leak detection	6

Related Issues

• High memory usage and database bloat in long-running OpenCode instances #16729 — High memory usage and database bloat in long-running instances
• [Critical] Memory leak causes kernel soft lockups (356s, 7/8 CPUs), OOM kills (111GB virt/21GB RSS), and total system death on Linux #13230 — Memory leaks during active usage
• SSE event streams leak memory on client disconnect #15645 — SSE stream memory leaks
• Memory leak #9385 — Subagent memory leak tracking
• memory leak #7046, Memory leak: Unbounded caches grow without limit #9140, 🐛 Issue: opencode memory usage keeps growing over time #11399, Memory leak: Uncleaned timeouts, intervals, and subscriptions #9156, Memory leak: serve and web commands leak child processes on exit; SSE heartbeat interval leaks on server-initiated close #14091, PTY handle leaks #15592 — Various memory growth reports

[binarydoubling]

I went through every open memory leak PR on this repo. What I found is, frankly, unacceptable.

23 open PRs. 20+ contributors. 0 merged. 63 days and counting.

The community has been screaming about this since January. Here's what's been sitting unreviewed:

@hendem submitted Bus subscription disposal fixes on January 6th. Had to rebase and resubmit on Jan 12th because the PR rotted. Got 30 review comments but still never merged. 63 days and counting.

@sauerdaniel opened 6 PRs in a single day on January 17th. SDK event listener cleanup (#8254), OAuth transport leaks (#9145), ACP session cleanup (#9146), TUI event listener leaks (#9147), timeout/interval cleanup (#9148), and Instance disposal chain (#9149). Every single one: 0 reviews, 0 comments. 52 days of complete silence.

@ztripez submitted a 15-file mega-fix on January 24th covering LRU caches, prompt loop cloning, pending timeouts, and more (#10392). 0 reviews, 0 comments. 45 days.

@Stranmor added TTL and LRU eviction across ACP sessions, Instance cache, LSP clients, and PTY ring buffers on February 5th (#12259). 0 reviews, 0 comments. 32 days.

@dzianisv reported 100GB+ RAM leading to a macOS crash from O(n²) string concatenation in processor.ts on February 11th (#13186). 0 reviews, 0 comments. 26 days.

@sebishogun, @feelsodev, @kryptobaseddev, @lytedev, @tda1017, @brendandebeasi, @NachoFLizaur, @dimaosipa, @GooseG17, @sjawhar, @jmylchreest, @BYK all submitted fixes between February and March. Almost all of them: 0 reviews, 0 comments.

15 out of 23 PRs have literally zero engagement from maintainers. No reviews. No comments. No "thanks, we'll look at this." No "this conflicts with internal work." Nothing.

Because nothing gets merged, contributors keep independently discovering and fixing the same bugs. lsp/client.ts has been independently fixed 7 times across 7 different PRs (#13594, #14650, #15435, #15646, #16346, #16695, #16730). session/prompt.ts, also 7 times. bus/index.ts, 6 times. tool/bash.ts, 5 times. plugin/index.ts, 5 times. app.tsx, 4 times. That's 20+ people writing the same fixes for the same bugs because the first person's fix was never reviewed.

Meanwhile, users are reporting:

• 16.4 GB RSS in a 3-hour session (fix: clear tool output and attachments when pruning to prevent memory leak #7049, reported Jan 6, 63 days ago)
• 100GB+ RAM causing macOS crashes (fix: resolve memory leaks and zombie processes from missing cleanup handlers #13186, reported Feb 11)
• 15GB over 24 hours leading to a kernel panic (fix(lsp): ignore stderr on LSP server spawn to prevent unbounded memory growth #16241, reported Mar 5)
• 2.3 GB/min virtual memory growth (fix(opencode): unbounded memory growth during active usage #16346)
• 2.9GB+ per session in serve mode (fix: add idle-timeout Instance disposal for serve mode memory #16616)
• 1.99 GB SQLite database with no cleanup whatsoever (fix(opencode): reduce memory usage and database bloat in long-running instances #16730)

People are having their operating systems crash. Their laptops are thermal throttling. They're restarting opencode every couple hours as a workaround for bugs that were fixed by the community months ago.

The fixes exist. All 23 of them. They just need to be merged.

A maintainer needs to triage these PRs, identify the best version of each fix (since many overlap), coordinate the rebasing, and start shipping. The longer this waits, the worse the merge conflicts get, and the more contributors give up and walk away.

Related PRs for reference: #7032, #7049, #7914, #8254, #9145, #9146, #9147, #9148, #9149, #10392, #12259, #13186, #13194, #13514, #13594, #14650, #15326, #15435, #15646, #15757, #16241, #16346, #16616, #16628, #16695, #16730

[rothnic]

I'm not sure why I finally decided to search around about this, but probably because things have gotten kind of out of hand lately? I can't go very long without my laptop, with 32GB of ram, and nothing running but a browser (min tabs open) and ghostty (with memory bug fix installed) becomes unusable.

I'm running multiple projects in parallel and often will notice things really slow down when the used ram exceeds what is available and I assume it is paging. I have seen ~60GB+ of usage multiple times, which I don't have.

I do wonder at time how much of this is related to agents spawning processes, like development servers, or tests which aren't cleaned up. I've tried some of the process management plugins, but overall haven't had good luck. It is promising to see that there are many fixes though, because this is nearly unusable.

[binarydoubling]

Yeah, it's really frustrating. I imagine the maintainers have way too much on their plate, this project grew EXPONENTIALLY in size and now it's just an amalgamation of conflicting issues, PRs, and bugs that they can't reasonably get to in time. And what makes it worse is that this isn't exactly a small project, it's something I've used extensively myself and nothing else quite matches the DX here. I genuinely love OpenCode and think it's arguably the best general-purpose coding agent out there but the amount of memory leaks in here are just.. it's unacceptable and unwieldy. People in the Discord talk about it, too, it's just getting buried underneath the devs' internal roadmap and more pressing bugs/feature releases. This needs to get prioritized though, cuz stuff like this turns power users away, HARD.

[binarydoubling]

Consolidated fix PR: #16695

I reviewed every one of the 23+ open PRs listed in this issue, analyzed the diffs, identified overlapping fixes, and consolidated the best version of each into a single PR: #16695 (branch fix/memory-leaks).

Coverage: 30 files, 3 commits

The PR addresses the following categories from the issue table:

Category	Status	Details
TUI event listeners	✅ Fixed	onCleanup for all sdk.event.on() calls in app.tsx, prompt, session route
Unbounded Maps/Sets	✅ Fixed	Bus/RPC empty entry deletion, diagnostics LRU cap (200), open-files cap (1000), LSP index teardown
Timer/interval leaks	✅ Fixed	Leader timeout, models refresh, state disposal timeout, theme SIGUSR2
Session data retention	✅ Fixed	Sync store frees previous session data, clearSession() on Permission/Question/FileTime
Plugin subscriber stacking	✅ Fixed	unsub?.() before re-subscribing in Plugin.init()
Message array retention	✅ Fixed	Event queue capped at 1000
Subagent deallocation	✅ Fixed	Session.remove() after task tool completion
SSE stream leaks	✅ Fixed	Centralized cleanup() with done guard on all 3 SSE endpoints
Process/Bus cleanup	✅ Fixed	Instance.disposeAll() with 5s timeout on exit, serve cmd graceful shutdown
Subscription disposal	✅ Fixed	Format, ShareNext, Plugin all store and cleanup unsub handles
Tool output retention	✅ Fixed	output = "", attachments = undefined on compaction prune
OAuth transport leaks	✅ Fixed	Close existing transport before replacing
Bash tool output	✅ Fixed	Chunks array with 10MB ring buffer instead of O(n²) +=

Items left for follow-up PRs

These are valuable but architecturally significant enough to warrant separate review:

• Instance idle-timeout disposal (serve mode ref counting) — fix: add idle-timeout Instance disposal for serve mode memory #16616
• LSP stderr "ignore" (40+ spawn site changes) — fix(lsp): ignore stderr on LSP server spawn to prevent unbounded memory growth #16241
• Provider/SDK LRU caches (new cache abstraction) — fix(opencode): memory leaks in session handling #10392, fix(disposal): Complete Instance disposal chain for plugins and caches #9149
• ACP session TTL/eviction — fix(memory): add TTL, LRU eviction, and ring buffers to prevent memory leaks #12259, fix(acp): Fix memory leak in session event streams #9146
• Startup cleanup/maintenance system (config schema, vacuum) — feat: add startup cleanup and maintenance system #16628
• O(n²) string concat in processor.ts (throttled flush) — fix: resolve memory leaks and zombie processes from missing cleanup handlers #13186
• Database config (auto_vacuum, WAL checkpoint, retention) — fix(opencode): reduce memory usage and database bloat in long-running instances #16730
• SDK-level fixes (SSE buffer cap, abort { once: true }) — fix: resolve memory leak issues across multiple subsystems #14650

The goal was to ship the highest-impact, lowest-risk fixes in one shot. The remaining items are individually reviewable without blocking on this PR.

cc @binarydoubling @sauerdaniel @hendem @ztripez @dzianisv @kryptobaseddev @brendandebeasi @GooseG17 — thank you all for the incredible work identifying and fixing these. This PR wouldn't exist without your contributions.

[NachoFLizaur]

hi @binarydoubling, thanks for the incredible work you've done consolidating these! I haven't seen the PR that I did (#15757) mentioned in the one you've done (#16695), have I missed it or did you not include it in there?

[binarydoubling]

@NachoFLizaur Great catch — just added your PR #15757 (robust process exit detection) to the consolidated branch! It's now in commit 36b93df on PR #16695.

Included:

• Polling watchdog in bash tool + Process.spawn to detect exit when Bun misses events
• Process registry (active map) with stale()/reap() exports for server-level cleanup
• Shell.killTree improvements with alive() helper and proper SIGKILL escalation
• Session-level watchdog interval in the prompt loop

You're credited as co-author on the commit. Thank you again.