Repository navigation
[Bug] Bun.exe is consistently using up to 2GB of RAM #6135
Description
Activity
- changed the title
[-]Bun.exe is consistently using up to 2GB of RAM[/-][+][Bug] Bun.exe is consistently using up to 2GB of RAM[/+]on Sep 27, 2026 - addedneeds-infoWaiting on reporter for a concrete spec or reproductionWaiting on reporter for a concrete spec or reproduction
on Sep 28, 2026 2 GB RSS on 2.66 is actionable, but the current report does not yet distinguish retained response state from Bun/native/runtime growth. Please update to the current 2.69 release and attach three same-process snapshots, 5–10 minutes apart, from
ocx observe memory --json(or the Memory/runtime section ofocx doctor): PID, Bun version, rss, external, arrayBuffers, heapUsed/jscHeap, observedMetric, responseState count/totalBytes/largest/oldest, and streamMode. Please capture after startup, after one Settings save, and after an idle interval, and tell us whether RSS continues growing with no requests. Remove tokens and account identifiers before posting.appOwnedMemoryBudgetMbis a retained-app-state budget, not an RSS cap. This may share the known Bun 1.3.14 streaming/runtime family, but I am keeping it open pending attribution.- addedplatformOS/service/tray/ACL (Windows-heavy, not Windows-only)OS/service/tray/ACL (Windows-heavy, not Windows-only)
on Sep 28, 2026 The latest version no longer shows any abnormal BUN issues.
Thank you for the great project and for resolving the issue so quickly. Excellent work!Thanks for confirming that the abnormal Bun behavior no longer occurs on your latest version. I am treating this as reporter-confirmed recovery, not evidence that all 2 GB RSS cases share one cause or that an application state budget is a process RSS cap. Since the issue is already closed and there is no new failing evidence, I will not start a new memory stress run. If it returns, the same-process version/memory/retained-state snapshots requested above will help distinguish recurrence from a different allocation path; omit account data and request contents.
Reacted by DevHero
Client or integration
Other
Area
Dashboard
Summary
Hi
I found that the OpenCodex web interface becomes unusually slow when changing or updating Settings, even though it is running locally.
After checking the running processes, we found that bun.exe is consistently using up to 2GB of RAM, even when there is no active processing and VS Code is not running.
Reproduction
Version
2.66
Operating system
Windows 11 Enterprise 25H2
Provider and model
chatgpt
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks