Repository navigation
Desktop app extremely slow/hangs at startup due to massive opencode.global.dat (179MB+) caused by base64-encoded PDF attachments in prompt history #34215
Description
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:
- Store attachments as separate files in a
blobs/directory, referenced by ID - 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
Activity
M330570912 commentedon Jun 30, 2026
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 commentedon Jul 13, 2026
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?
github-actions commentedon Sep 12, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.