Repository navigation
Sessions become unusable due to large LSP diagnostics (Lua + possibly others) #6310
Description
Description
After using the edit/write tools a few times in larger LSP enabled Lua (.lua extension) projects, sessions slow to a crawl.
Root Cause
- Edit/write tools store full LSP diagnostics in metadata.
- Lua LSP returns diagnostics for entire workspace (for me thousands of files, tens of thousands of diagnostics
- This bloats session storage rapidly, as full diagnostics are attached to EACH message that does an edit/write tool call.
- Other LSPs may have the same issue.
Impact
- OpenCode session grows to 1GB+ quickly
- New messages takes minutes to send: OpenCode sits at 100% CPU usage (presumably decoding JSON).
- Cancelling via ESC becomes unresponsive.
Workaround
- Disabling LSP works around the issue: https://opencode.ai/docs/lsp/#disabling-lsp-servers
Potential fix
In packages/opencode/src/tool/edit.ts and write.ts, change from storing the entire diagnostics object to just the edited file's diagnostics:
+++ b/packages/opencode/src/tool/edit.ts (or write.ts)
return {
metadata: {
- diagnostics,
+ // Only store diagnostics for the edited file, not entire workspace
+ diagnostics: { [normalizedFilepath]: diagnostics[normalizedFilepath] ?? [] },
Additional context (which Opus 4.5 found)
Commit aedb555 ("fix: limit LSP diagnostics to prevent context window waste") also addressed a related problem of sending too many diagnostics to the LLM, by limiting the output message to max 20 diagnostics per file and max 5 project files.
However, that commit only limited what goes in the tool's output string shown to the LLM. It didn't touch the storage layer - the full workspace diagnostics (all files, all issues) were still being saved to session metadata on every edit/write. Your proposed fix compliments that work by also limiting what gets persisted to disk.
OpenCode version
1.0.204 (latest as of writing)
Steps to reproduce
- Extract the test project ZIP (contains 1000 test lua files + an AGENTS.md to tell the agent to continue the pattern)
- Start
opencodein that folder and send a message. - Watch how a 44.3MB json file gets created under
opencode/storage/part/, containing diagnostics of all 1000 files, even tho the agent only touched 2 files.
Screenshot and/or share link
Operating System
Linux Mint 21.3
Terminal
Guake
Activity
ry2009 commentedon Jan 2, 2026
done a couple things with lsp budget and diagnostic here is targeted one: #6671
mblarsen commentedon Feb 27, 2026
Also happens for python (pyright)
opencode version 1.2.15
maurits150 commentedon Feb 27, 2026
Yup this is still a problem - tested again using test project ZIP
18MB additional disk used for 1 message
Forgot to do
opencode -vthere but it's1.2.15.mengdehong commentedon Mar 4, 2026
The same problem exists in Rust
opencode: disable LSP, enable compaction pruning (#83)
Mart-Bogdan commentedon Jun 4, 2026
Strange. for C# it ouputs diagnostics only for currently edited file
full-bars commentedon Jun 24, 2026
Confirming this is still present in opencode 1.17.9 (current as of writing), well after PR #6671 was closed without merging back in March.
New data point: also reproduces with Go (gopls), not just Lua/Python/Rust. In my case it was worse than just slowness — it crashed the process entirely. A ~66K-line generated Go file (a data table, not hand-written code) triggered gopls's
simplifycompositelithint once per line (~65,871 diagnostics). Because that file existed in 3 separate LSP workspace roots in my config, the same diagnostics array got duplicated 3x per snapshot. Eachedit/writetool-call part ballooned to ~67MB regardless of how small the actual edit was. Over a long session (7,576 tool-call parts) that's 2.05GB of part data for one session.Beyond the slowness described above, once a session crosses this size,
opencode -chard-crashes with SIGABRT trying to resume it — andopencode exportfails too (see #22072, same root cause: uncapped diagnostics growth, just surfacing as a different symptom).The fix proposed in #6671 (scope diagnostics to the touched file) looks right, but might also need to dedupe identical diagnostics across multiple LSP roots for the same logical file, since that's what pushed my case from "annoying" to "crashes the app."
Workaround I'm trying in the meantime: disable the specific noisy analyzer via opencode config (e.g. for gopls,
"analyses": {"simplifycompositelit": false}inlsp.gopls.initialization). Note this is untested for long-term effectiveness — I haven't yet confirmed it actually prevents bloat from recurring over a fresh long session, and it's per-analyzer/per-LSP, not a general fix.github-actions commentedon Aug 24, 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.
maurits150 commentedon Aug 24, 2026
??
Mart-Bogdan commentedon Aug 24, 2026
Yes, it's wild that they've set up auto close on issues.
one-pyy commentedon Oct 5, 2026
Hit exactly this and, since the issue only auto-closed for inactivity (people still confirm it on newer versions), I put together a workaround plugin while waiting for an upstream fix.
opencode-edit-diagnostics-pruner — https://github.com/one-pyy/opencode-edit-diagnostics-pruner
tool.execute.afterhook that rewrites the tool result sostate.metadata.diagnosticskeeps only the files edited by that call (apply_patch,edit,write). Tooloutput, title,input, and provider metadata are preserved, and the diagnostics text returned to the model is unchanged — so neither the UI replay nor the model feedback changes, only the persisted map shrinks.history.mjs) that prunes the same diagnostics from an existing session database, for sessions that already ballooned. It takes a full SQLite online backup first, validates it, and applies every change in a single transaction (with an explicit--no-backupopt-out).On my database the history cleanup removed ~540 MB of diagnostics JSON (327 parts + 327 event copies). For the affected session, send time went from ~59s to ~6s and sampled peak memory from ~9.75 GiB to ~2.54 GiB — single measurement, not a promise. The gain scales with session length and with how many plugins pass that metadata around. It does not address the
eventtable growth in #33356, only the diagnostics payload.Not affiliated with the project; sharing in case it helps anyone until upstream trims the persisted diagnostics.