High memory usage and database bloat in long-running OpenCode instances

[BYK]

Description

A long-running OpenCode server instance (2+ days) consumes 1.76 GB (602 MB RSS + 1.15 GB swap) on an 8 GB system. The SQLite database grows to 1.99 GB with no automatic cleanup — 1,706 sessions spanning 53 days, 274K parts (1.49 GB) never pruned.

Root causes identified:

• No data retention — sessions are only soft-archived, never deleted
• auto_vacuum = OFF — deleted data never reclaims disk space
• No periodic WAL checkpoint — WAL file grows unbounded during long sessions
• Compaction marks parts but keeps full data — dead weight in SQLite
• Bash tool output accumulates unboundedly — verbose commands can grow to hundreds of MB in the output string
• Edit tool Levenshtein uses O(n×m) matrix — can spike to ~400 MB for 10K char strings
• FileTime per-session tracking never pruned — slow memory leak over instance lifetime
• RPC pending map has no timeout — orphaned promises leak if workers die
• LSP diagnostics Map grows monotonically — empty entries never deleted

Measured metrics:

Metric	Value
Main process RSS	602 MB
Main process swap	1.15 GB
Peak RSS (VmHWM)	1.64 GB
SQLite DB size	1.99 GB
DB parts table	1.49 GB
Sessions	1,706 (never auto-deleted)
auto_vacuum	OFF

Plugins

No plugins

OpenCode version

0.1.44 (dev build)

Steps to reproduce

1. Run opencode serve on a machine with 8 GB RAM
2. Use it actively for 2+ days with multiple worktrees
3. Monitor RSS with ps aux or /proc/<pid>/status — memory grows monotonically
4. Check opencode.db file size — grows without bound since archived sessions are never deleted

Screenshot and/or share link

N/A

Operating System

Ubuntu 22.04 (Linux x86_64, 8 GB RAM, 16 GB swap)

Terminal

N/A (headless server mode via opencode serve)

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The issue does not use one of the required templates (Bug Report, Feature Request, or Question). Please resubmit using the appropriate template.
• If this is a Bug Report, the template requires: a Description field, steps to reproduce, OpenCode version, and OS/environment information. None of these are present.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Multiple memory leaks cause unbounded RAM growth during extended TUI usage #16697: Multiple memory leaks cause unbounded RAM growth during extended TUI usage — overlaps on LSP diagnostics map growth and in-memory leaks
• [FEATURE]: Session Lifecycle Management — unified storage reclamation, auto-archival, and child session cleanup #16101: Session Lifecycle Management — overlaps on database bloat, no data retention, SQLite VACUUM, WAL checkpointing, and compaction not clearing data
• High disk writes and memory spike during long opencode sessions on macOS #14876: High disk writes and memory spike during long opencode sessions on macOS — similar symptoms (memory + disk growth in long sessions)
• Memory usage grows very quickly when running commands with large output #9699: Memory usage grows very quickly when running commands with large output — overlaps on bash tool output accumulation

If you believe this was flagged incorrectly, please let a maintainer know.

[binarydoubling]

Went ahead and tagged you up, this needs more attention and there's a lot to be done. Had my poor MacBook crash way too many times.

[github-actions]

This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new issue that follows our issue templates.

[BYK]

Reformatted to match the bug report template. Reopening.

[jnorthrup]

Comprehensive Memory Analysis - Related Findings

Your analysis of long-running OpenCode instances is extremely thorough. We found similar patterns in Bun runtime investigation.

Confirmed Leak Sources (Matching Our Findings)

Your identified sources align with our JSC GC investigation:

• ✅ Bash tool output accumulates unboundedly → We found similar in shell tool buffers
• ✅ LSP diagnostics Map grows monotonically → We found this in JSC GC HashMap
• ✅ No periodic cleanup → We found GC marking phase never completes
• ✅ SQLite never pruned → Similar to our session storage leaks

Additional Context

Hardware Risk: On Apple Silicon Macs, memory exhaustion leading to kernel panic → forced power cycle → potential SOC damage (non-replaceable, $500-1500 hardware loss).

Our Investigation

We built an ASAN tracker that identified 4 unique JSC GC leaks:

• JSC::SlotVisitor::drainFromShared race
• WTF::HashTable::removeIterator
• WTF::Vector<>::operator=
• JSC::ASTBuilder::createForOfLoop

Cross-Project Issue

This affects all WebKit-based runtimes. We're coordinating upstream:

• Bun tracking: Tracking: JavaScriptCore GC Memory Leaks - Upstream WebKit Issue oven-sh/bun#28343
• WPEWebKit OpenAI OSS tool calling #1622
• WebKit #200863

Your 8 root causes + our 4 JSC GC leaks = comprehensive picture of WebKit memory issues.