Repository navigation
fix(session): Memory keeps growing until the bun process is killed. #35107
Description
Description
updatePart calls structuredClone(part) on every part update. Text parts accumulate content as tokens stream in (up to 488 KB per part). With ~93K PartUpdated events over 200 sessions,, this creates massive heap pressure.
Root Cause
Bun's allocator (mimalloc) does not return freed pages to the OS, so RSS grows continuously — observed ~450 MB at startup → 8 GB after 20 h.
Proposed Fix
Remove structuredClone. The PartUpdated projector only destructures the part and writes to SQLite — it never mutates the original object. opencode/packages/opencode/src/session/session.ts:
const updatePart = <T extends SessionV1.Part>(part: T): Effect.Effect<T> =>
Effect.gen(function* () {
yield* events.publish(SessionV1.Event.PartUpdated, {
sessionID: part.sessionID,
part,
time: Date.now(),
})
return part
}).pipe(Effect.withSpan("Session.updatePart"))- Process RSS before fix: 500 MB → 8 GB over 200 sessions,
- Process RSS after fix: stable at ~500 MB
- The
PartUpdatedprojector (session/projectors.ts) only reads frompart:const { id, messageID, sessionID, ...rest } = data.part db.insert(PartTable).values({ ... data: rest }).onConflictDoUpdate(...)
It works fine for several days.
Plugins
No response
OpenCode version
1.17.8
Steps to reproduce
- run opencode web
- Multiple users on the local area network are using it concurrently. After one day, there are about 200 sessions, and after multiple rounds of dialogue.
- check the memory status.
Screenshot and/or share link
No response
Operating System
Ubuntu24.04
Terminal
Bash
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jul 3, 2026
This issue might be a duplicate of or related to existing issues. Please check:
opencode web/opencode serve) memory growth.Your specific analysis of
structuredCloneinupdatePartis a concrete and useful finding. If you haven't already, consider also uploading a heap snapshot following the instructions in #20695 to help the maintainers confirm and prioritize the fix.Hubxx520 commentedon Jul 3, 2026
这个问题确实存在，请予以重视，不能未来堆功能而忽视内存损耗。
1884000 commentedon Jul 3, 2026
+1
shashb27 commentedon Aug 20, 2026
Triage: linked PRs do not address this issue
Cross-checking the PRs linked to this issue, neither actually fixes the
structuredClone(part)leak described here:PR #42150 — targets a different bug
fix(opencode): make text/reasoning delta accumulation O(N) instead of O(N²)packages/opencode/src/session/processor.ts), not thestructuredCloneheap growth inpackages/opencode/src/session/session.tsdescribed in this issue.PR #35111 — the real fix, stale-closed
@xingruodong-sys). Branchfix/35107-memory-grows. Title matches this issue. Closed 2026-08-03 by thegithub-actionsstale-PR bot ("Automated PR Cleanup: >1 month old, <2 positive reactions"), not by a maintainer.Net status
No merged or open PR currently addresses #35107. The issue is effectively unowned right now.
Suggested next step
A maintainer should decide one of:
structuredClone(part)→partremoval, guarded by confirming the projector insession/projectors.tsonly destructures/inserts and never mutatespart).I'm happy to open a clean PR if a maintainer confirms. Not opening one unilaterally to avoid duplicating #35111.
(Context: I hit this while investigating memory bloat in my own opencode sessions — reported in capsule oxmiq/capsule#1762. The
structuredCloneper-PartUpdated path is the strongest match for "many subagents + tokens = RSS growth" among the open upstream issues.)fix(tui,opencode): stop long-session RAM accumulation
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊