Repository navigation
memory leak #7046
Description
Description
Plugins
oh-my-opencode
OpenCode version
1.1.3
Steps to reproduce
No response
Screenshot and/or share link
Operating System
windows11
Terminal
windows terminal
{{ message }}
oh-my-opencode
1.1.3
No response
windows11
windows terminal
Activity
github-actions commentedon Jan 6, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
hffmnnj commentedon Jan 6, 2026
+1
wzx140 commentedon Jan 7, 2026
+1
kfuglsang commentedon Jan 7, 2026
Can confirm the memory leak is quite bad on Windows. Typically have to kill OpenCode every 30 minutes (on a 32gb machine).
Just had a long-running prompt (i18n extraction in a codebase) that only did file reads and file writes for a period of time. This alone was clearly leaking as the Bun process raised from initially ~500mb memory to ~1,3gb in a few minutes, and still climbing.
DuckForgeDev commentedon Jan 8, 2026
I'm using OpenCode on Windows 11 with PowerShell 7. After launching OpenCode, even if I don't initiate any conversation, the memory usage keeps increasing until it completely cripples my system. From Task Manager, I can see that numerous PowerShell processes are being spawned continuously, and new ones keep launching nonstop. I don't understand what's causing this issue.
feat(desktop): add hardware acceleration toggle for Windows
ShuraWW commentedon Jan 27, 2026
+1
HexaField commentedon Feb 1, 2026
i'm trying to build on the opencode sdk and with just a few tests in a test suite my system quickly runs out of memory
reachcreator commentedon Feb 2, 2026
Yeah this issue has definitely returned. Just managed to close it down before it crashed my 32gig box with just one OpenCode open and not doing anything else...
kryptobaseddev commentedon Feb 22, 2026
This is still reproducing as of the latest dev branch. I traced four specific leak sources from this issue and fixed them in #14650:
Tool output survives compaction —
compaction.tsprune()setstime.compactedon tool parts but never clearsstate.outputorstate.attachments. The strings stay in both the DB and the in-memory store.toModelMessagesalready substitutes"[Old tool result content cleared]"for compacted parts, so the data was being kept for nothing. Fix: clear output/attachments when compacting.LSP diagnostics map grows without bound — The
diagnosticsMap inlsp/client.tsand thefilestracking object accumulate entries for every file ever touched. Added FIFO eviction caps (2,000 diagnostics, 1,000 open files).Pending permissions leak on session delete —
Session.remove()didn't clear pending permission entries for the deleted session. AddedPermissionNext.clearSession()that rejects and removes them.TUI event listener accumulation — 8
sdk.event.on()calls acrossapp.tsx,session/index.tsx, andprompt/index.tsxnever saved their unsubscribe functions. Each component remount added duplicates. Fixed withonCleanup()handlers.The tool output issue (1) compounds with the delta accumulation problem — together they're what causes the 30+ GB growth @reachcreator and @HexaField are seeing in extended sessions. The PR caps delta strings at 1 MB per part field and adds a 10 MB SSE buffer guard as well.
Tested with a 2.5-hour session including heavy tool use and subagent tasks. RSS held steady at ~2,500 MB instead of climbing unbounded.
aniel300 commentedon Feb 22, 2026
I am still seeing high ram usage 😭🤦♂️
fix: memory leak - unbounded virtual memory growth during active usage
thdxr commentedon Apr 2, 2026
Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.