Possible Bug: Renderer OOM crash loop after updating to v1.17.18 #36218

Activity

1. github-actions

   assigned

   Brendonovich

   on Jul 10, 2026
2. github-actions commented on Jul 10, 2026

   

   github-actionsBot

   on Jul 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • event table bloat from message.updated.1 causes OOM when loading old sessions #32005: Very similar — same OOM crash (reason: 'oom', exitCode: -536870904), same call stack through constructMessageRows → MessageTimeline, triggered by large session history on Windows with Electron 42.3.3. Likely the same root cause.
   • Renderer process memory leak — 2.5 GB RAM + 70% CPU within 4 minutes on fresh session (Windows 11) #28680: Renderer process memory exhaustion on Windows 11, same symptom of monotonically growing memory until crash.
   • Memory Megathread #20695: Active memory megathread where maintainers are collecting heap snapshots to diagnose renderer memory issues — consider contributing a heap snapshot there following the instructions in that issue.

   If your issue is distinct from those (e.g. specific to v1.17.18 or a regression from v1.17.15), please add a note clarifying the difference.
3. MrNova420 commented on Jul 10, 2026

   

   MrNova420

   on Jul 10, 2026

   Author

   More actions

   it is similar to #32005 ...but that issue was reasled a month ago and still has issues, so still needs handled.
4. d34DMK1 commented on Jul 11, 2026

   

   d34DMK1

   on Jul 11, 2026

   More actions

   Confirming this on a second independent report (I filed #36379 before the bot flagged it as a duplicate of this one - closing mine in favor of this). Same version (v1.17.18), same Windows 11, same exact stack trace.

   A few data points that might help narrow down the root cause, since they weren't in the original report:

   • Message count: the affected session had ~2,956 raw rows in the message table at time of first freeze, growing to ~3,164 after some interaction. The next-largest session anywhere else in the same local install (many other projects/sessions) was 647 - roughly 4-5x smaller. So this does seem to scale with raw message count specifically, not just general session age.
   • /compact does NOT fix it. Ran /compact via the CLI/TUI on the affected session (which worked fine there - see below). The raw row count in the message table was unaffected by compaction (it stayed just as large / grew slightly from the compact operation's own messages), and reopening the session in the desktop app still hung afterward. This is consistent with your theory (Possible Bug: Renderer OOM crash loop after updating to v1.17.18 #36218) that the issue is unbounded SolidJS reactive memo growth over the full raw message set, since compaction only affects what's sent to the model as context, not the raw row count the renderer has to process.
   • The TUI opens the same session without hanging - it appears to hardcode a ~100 message load limit ([BUG] Cannot scroll to beginning of long conversations (message limit hardcoded to 100) (#6138) #6137), which may be why it dodges this entirely. Might be a useful reference point for a workaround/mitigation (cap the desktop timeline's initial load similarly) while the underlying reactive-disposal bug is fixed.
   • Not a database corruption issue - ran PRAGMA quick_check on the SQLite DB directly, returned ok. Pure rendering-side issue.

   Workaround that's worked for us in the meantime: access the affected session via CLI (opencode -s <session-id>) instead of the desktop app.
5. Alex-Blanes commented on Jul 19, 2026

   

   Alex-Blanes

   on Jul 19, 2026

   Last edited by Alex-Blanes

   More actions

   Same issue here - v1.18.3 Windows x64

   Same crash since updating to v1.18.3. Renderer OOM within 30-85 seconds of startup.

   Stack trace (identical to reported):
   \
   constructMessageRows → createTimelineProjection → MessageTimeline → loadMessages → applyMessagePage
   \\

   System: Windows 11 x64, 16GB RAM, OpenCode Desktop v1.18.3 packaged

   What I tried that didn't help:

   • Cleared Cache + Crashpad directories
   • Deleted 4 largest sessions from the database (removed ~45% of events)
   • Ran VACUUM on the database
   • Set OPENCODE_AUTO_HEAP_SNAPSHOT=1 (no snapshot was generated)

   RAM trace during crash:
   After session cleanup, the desktop app still consumed ~5.7 GB of RAM in 85 seconds before dying:

   Time	Total WS	Processes	Note
   T+0s	1.2 GB	baseline	App opens
   T+15s	2.7 GB	24 procs	Growing
   T+45s	4.5 GB	24 procs
   T+75s	5.5 GB	24 procs
   T+85s	5.7 GB	24 procs	Last reading before OOM

   Memory was growing at ~67 MB/s. The \event\ table in the database still has 11,806 rows (173 MB) across 28 sessions — the renderer creates SolidJS reactive wrappers for all of them.

   The database is stored at ~/.local/share/opencode/opencode.db\ (not in the userData dir mentioned in the manifest).

   Let me know if you need any specific debug info. I can provide sanitized logs (without local paths) if helpful.
6. github-actions commented on Sep 19, 2026

   

   github-actionsBot

   on Sep 19, 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.
7. github-actions

   closed this as not plannedon Sep 19, 2026