Orphaned opencode-wal-*.db files accumulate in $TMPDIR and can consume hundreds of GB #36831

Activity

1. github-actions

   assigned

   rekram1-node

   on Jul 14, 2026
2. asanre commented on Jul 29, 2026

   

   asanre

   on Jul 29, 2026

   More actions

   Confirming this on 1.18.8 (macOS, Apple Silicon). Also reproduced on 1.18.7 — updating does not help.

   Hit 214 GB across 106 files in roughly 20 hours, which took a 460 GB disk down to 2 GB free twice in two days.

   The files are created on a fixed 5-minute timer, not per session

   The report above guesses "one new file per session/restart". That does not match what I measured. I took the epoch-ms timestamps from the 104 orphaned files and computed the deltas between consecutive files:

   Interval between files	Occurrences
   300 s	60
   299 s	27
   ~600 s / ~1000 s / ~1843 s	6 total

   87 of 93 intervals are exactly 300 seconds. The handful of larger values are near-multiples of 300 s, i.e. ticks skipped while the app was closed or idle. This is a periodic checkpoint on a 5-minute timer, independent of session count or restarts. Worth knowing for whoever fixes it — the cleanup hook belongs on the timer, not on session teardown.

   Each file is a full copy of opencode.db, byte for byte

   2160320512  ~/.local/share/opencode/opencode.db   (live DB)
   2160320512  $TMPDIR/opencode-wal-<newest>.db      (identical size)
   2152824832  $TMPDIR/opencode-wal-<oldest>.db      (earlier state, smaller)
   

   They are not SQLite WAL files despite the name — file(1) reports them as complete SQLite 3 databases, and they carry the full schema (session, message, part, event, migrations). The name is misleading enough that users may hesitate to delete them, thinking they hold session history.

   Why this hits some users catastrophically and others not at all

   The leak rate is DB size / 5 minutes. So it scales with how big opencode.db has grown, which is governed by #33356 (unpruned event table).

   My instance:

   Metric	Value
   opencode.db	2.07 GB
   Sessions	1,120 (910 of them sub-agent sessions)
   Events	81,396
   event table	1,374 MB — 66% of the DB
   History retained	~4 months, never pruned

   That works out to ~24 GB/hour, or ~600 GB/day if the app stays open. A colleague on the same version saw nothing, because their DB is ~100 MB — the same bug leaks ~1 GB/hour for them and they never notice.

   So the two issues compound: #33356 inflates the DB, #36831 copies it every 5 minutes forever. Heavy sub-agent workflows accumulate sessions fast and land squarely in the bad case.

   Note on the workaround above

   tail -n +2 keeps only the newest file. I'd suggest tail -n +3 instead — keeps two, costs one extra copy, and leaves a recovery point in case the live DB is mid-write:

   ls -t "$TMPDIR"/opencode-wal-*.db | tail -n +3 | xargs rm -f

   I verified no process held a handle on any of them before deleting, and the live DB was unaffected.

   Possibly related: #37495 describes multiple concurrent SQLite connections preventing WAL checkpointing. If the 5-minute snapshot exists to hand a consistent view to a secondary reader, that would tie the two together — but I haven't confirmed that from the source.
3. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
4. github-actions

   closed this as not plannedon Sep 29, 2026