Repository navigation
opencode.db hit 7.45 GB / 721k event rows on 1.18.33 with no prune or cleanup command available to users #52936
Description
Description
opencode.db reached 7.45 GB (8,004,255,744 B) on a normal long-running session and kept growing between two reads (confirmed +6 MB in a few minutes). The growth is entirely in the event table, and v1.18.33 ships no prune/cleanup command, so there is no user-side remediation.
Environment
- opencode: 1.18.33
- OS: Windows 11 24H2, terminal: Windows Terminal
- DB:
C:\Users\zhang\.local\share\opencode\opencode.db
Measured (read directly from SQLite, not estimated)
| table | rows | bytes |
|---|---|---|
event |
721,703 | 6.68 GB (avg 9,258 B/row) |
part |
180,081 | 0.41 GB |
message |
42,264 | 149.7 MB |
session |
713 | — |
event.type breakdown:
message.part.updated.1 511,375
message.updated.1 163,483
session.updated.1 45,809
session.created.1 703
So for this build the dominant amplifier is message.part.updated.1, not message.updated.1 — each streaming chunk appends one row and event.data stores a full part snapshot (~9.2 KB per row). No retention policy, no deletion.
Symptom on the running process: UI/session unusable, RSS ballooned to 849 MB.
Missing piece (the actionable part)
opencode --help on 1.18.33 matches zero occurrences of prune|clean. There is no config key for retention either. So even a user who notices the 7 GB file cannot do anything but delete the whole DB and lose all 713 sessions.
Workaround that did work
Stop the process, rename (not delete) opencode.db + -wal + -shm, relaunch. A fresh 4 KB DB is created and the tool works again. This is destructive though — no built-in way to keep the sessions.
Related
- opencode.db grows to ~9 GB due to enormous message.updated.1 event snapshots #46833 — same root cause, attributes it to
message.updated.1/summary.diffs(different event type, same unboundedeventtable) - feat(cli): add session prune command #51254 / feat(cli): add session prune command to v2 #51255 —
session prunecommand, still open, wanted here in 1.18.x - [BUG] SQLite WAL grows unbounded (10–15 GB) while Desktop is running — disk fills to 0, recovers only on full quit #37495 — SQLite WAL unbounded growth on Desktop
- fix: disable SQLite mmap to prevent memory growing with DB size #22428 — disable SQLite mmap to stop RSS tracking DB size
Steps to reproduce
- Run opencode on a long coding session for a few hours.
ls -la ~/.local/share/opencode/opencode.db→ grows past several GB.- Sessions become unresponsive; process RSS climbs past 800 MB.
- No command in
--helpcan shrink it.
Activity
github-actions commentedon Oct 3, 2026
This issue might be a duplicate of existing issues. Please check:
opencode.dbgrowth caused by large snapshots retained in theeventtable.eventtable: opencode.db reaches 13GB+, mostlymessage.updated.1snapshots (no retention/compaction) #33356: Unboundedevent-table growth from retainedmessage.updated.1snapshots, with no retention or compaction.event-table growth with no retention policy or cleanup command.event-table growth from streaming events and no retention or maintenance command.YIbaikaishui commentedon Oct 3, 2026
Correction / extra finding after further forensics on the same 1.18.33 install.
I wrote that 1.18.33 has no cleanup capability. That is not accurate — I found a built-in job:
It appears 1485 times in
~/.local/share/opencode/log/opencode.logand runs at startup (and periodically) — so a prune path does exist.But it does not solve the problem, which is worth saying explicitly because it changes what the fix should be:
eventrows for those sessions in a way that shrinks the file — there is no evidence of aVACUUM/truncate, so the freed pages stay in the DB file and the file keeps its size.So the accurate framing is: the built-in 7-day session pruning is not a bound on
opencode.dbsize, and there is no user-facing knob for it. Please correct my title/uplift if needed.Repro note for anyone testing: fresh DB (4 KB) → one session with a long streaming run → the
eventtable alone had 511,375message.part.updated.1rows / 6.68 GB at 721,703 rows / 7.45 GB total, reached in a few hours of ordinary use, with the process RSS at 849 MB.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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊