Desktop app extremely slow/hangs at startup due to massive opencode.global.dat (179MB+) caused by base64-encoded PDF attachments in prompt history

[yedifeng]

Description

Symptoms

• The app becomes unresponsive for minutes after launch
• Task Manager shows ~40MB/s disk I/O during the freeze
• GPU/renderer process (Electron) consumes up to 4GB working set
• Over 7.5GB of read I/O accumulated within minutes

Root Cause
The file opencode.global.dat (stored at %APPDATA%\ai.opencode.desktop\opencode.global.dat) stores the entire app state as JSON, including prompt-history. When a PDF file is attached to a prompt, it is stored as an inline base64 data URL (data:application/pdf;base64,...) directly in the JSON. This causes unbounded growth:

Item	Value
Total file size	179 MB
prompt-history field	175 MB
Total PDF attachments	27 (across multiple sessions)
Largest single entry	75 MB (12 PDFs in one prompt)
Same PDF re-embedded	e.g., 图神经网络模型深度解析.pdf (16MB) stored 3 times

On every startup, the entire 179MB JSON is loaded and parsed, causing massive disk I/O and memory bloat.

Expected Behavior
Large file attachments (especially PDFs >1MB) should not be embedded as base64 in the main state file. Options:

1. Store attachments as separate files in a blobs/ directory, referenced by ID
2. Or at minimum, cap the prompt-history size and provide automatic archival/cleanup

Plugins

No response

OpenCode version

1.17.11

Steps to reproduce

1.在对话中多次附加大型 PDF 文件（如 16MB 的 PDF）
2.跨多个 session 重复附加同一份或多份 PDF
3.每次会话中 prompt-history 字段以 base64 形式内联存储所有附件
4.累积 27 个 PDF 附件（最大单次 12 个，175MB）
5.关闭并重新打开桌面端
6.观察到 app 卡死数分钟，伴随 7.5GB+ 磁盘读取和 4GB 内存占用
7.检查 %APPDATA%\ai.opencode.desktop\opencode.global.dat，文件大小超过 179MB

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

Windows Terminal

[M330570912]

Related issue: opencode serve API transfer extremely slow with large session JSON (300MB+)

I'm experiencing a similar issue but specifically with the opencode serve HTTP API.

Symptoms:

When calling GET /session/:id or GET /session/:id/message, the response takes a very long time to transfer
The session JSON is over 300MB in size
There is no way to filter out fields or limit the response payload
Root cause appears to be the same:

Base64-encoded attachments (images, PDFs, etc.) are stored inline in the session/message JSON
The API returns the full JSON without any field filtering option
What I've tried:

GET /session/:id/message?limit=10 — this helps for listing messages, but the session detail endpoint (/session/:id) still returns the full payload
There's no ?fields= or ?exclude= query parameter available
Suggestion: It would be helpful if the API supported one of the following:

Field filtering (e.g., ?exclude=attachments or ?fields=id,title,createdAt)
Store attachments externally (as proposed in PR #34011) and reference them by ID
Add a ?summary=true option that returns session metadata without inline attachments
This is a blocker for anyone using opencode serve programmatically with large sessions.

[achcyano]

A 145 MB PDF became an approximately 194 MB base64 attachment in tool.state.attachments. Multiple subagent reads produced about 561 MB of attachment data, persisted into both parts and events. Opening either the parent session or affected child session caused Electron black screens and browser/mobile OOM.
I can submit a focused fix that checks stat.size before fs.readFile() in ReadTool and returns an explicit error for oversized PDFs. Would maintainers prefer the previous 5 MiB limit from #19008, another fixed limit, or a blob-reference approach?