Startup permanently OOMs and bricks the app if any session's data fails schema validation (no graceful recovery)

Summary

When a session's stored data (message/part body) becomes large enough to fail schema validation, the entire opencode process OOMs on startup, every time, with no fallback or recovery path. Since the bad session lives in ~/.local/share/opencode/opencode.db and is loaded unconditionally at launch, this permanently bricks opencode for all sessions/projects — not just the offending one — until the user manually edits the SQLite database with an external tool.

This surfaced as a consequence of the PDF base64 leak in #42263, but the underlying problem here is broader and independent of that specific trigger: any mechanism that produces an oversized/malformed session body (leak, corruption, a future bug, etc.) can hard-brick the app the same way, because startup has no defensive handling for it.

Environment

• opencode version: 1.18.31
• OS: Linux
• Trigger in my case: a session with a PDF ingested twice via the read tool (see #42263) — two ~308 MB data:application/pdf;base64,... strings in part.data

Steps to reproduce

1. Get a session into a state where a part/message body is very large (e.g. via the PDF ingestion bug in #42263, ~300 MB+ per row).
2. Launch opencode.
3. Observe ~/.local/share/opencode/log/opencode.log:

   message="schema rejection" kind=Body reason="RangeError: Out of memory"
   

4. This repeats on every subsequent launch (run=<id> changes each time), RAM spikes, and the app never becomes usable — not just for the bad session, but at all.

Expected behavior

A single session with bad/oversized data shouldn't be able to prevent the whole app from starting. Startup-time loading/validation of session data should degrade gracefully per-session, e.g.:

• Catch validation failures per-session rather than letting one failure abort/OOM the whole process.
• Skip or quarantine the offending session (mark it unloadable, exclude it from the session list) and let the rest of the app start normally.
• Surface a clear, actionable error ("session X failed to load and was skipped") instead of a silent OOM crash loop.
• Optionally expose a CLI recovery command (e.g. opencode session repair/--skip-broken) instead of requiring manual SQLite surgery.

Actual behavior

opencode.db (1.4 GB in my case) is loaded/validated in full at startup; the two oversized rows fail schema validation and OOM the process (RangeError: Out of memory) before the TUI becomes usable. This happened on every launch attempt. I recovered by manually deleting the offending session's rows from SQLite (part, message, event, event_sequence, session) and running VACUUM, which is not something a typical user could be expected to do.

Related

• #42263 — the specific PDF base64-without-size-limit bug that produced the oversized data in my case. That issue's fix (size limits + caching) would prevent this particular trigger, but wouldn't address the lack of defensive handling at startup for oversized/malformed session data in general.