Memory leak: LSP client diagnostics and files maps not cleared on shutdown

[sauerdaniel]

Problem

When an LSP client shuts down, the diagnostics Map and files object are not cleared in the shutdown() method of LSPClient. This can cause:

1. Memory retention - Diagnostics data for closed files remains in memory
2. Stale data - If the same LSP server is reconnected, old diagnostics may persist
3. Memory growth - Over multiple LSP reconnections, maps accumulate entries

Code Location

packages/opencode/src/lsp/client.ts - The shutdown() method closes the connection but doesn't clear internal state.

Proposed Solution

Add cleanup calls in the shutdown() method:

diagnostics.clear()
for (const path in files) delete files[path]

Impact

• Minimal change (2 lines)
• Ensures clean state on LSP shutdown
• Prevents memory growth from accumulated diagnostics

Relates to #5363

[github-actions]

This issue might be a duplicate of or closely related to existing memory management issues. Please check:

• Memory leak: Unbounded caches grow without limit #9140: Unbounded caches cause memory growth over time
• opencode eating 70gb of memory? #5363: opencode eating 70gb of memory?
• v1.1.6 still has memory bloat - heap not released + MCP orphan processes #7261: v1.1.6 still has memory bloat - heap not released + MCP orphan processes
• [FEATURE]: TUI whole and LSP memory limits as part of configuration #8947: [FEATURE]: TUI whole and LSP memory limits as part of configuration

These issues all address memory retention and cleanup problems in OpenCode, including LSP-related memory leaks. Your proposed fix for clearing diagnostics and files maps in LSPClient.shutdown() is directly addressing part of the root cause identified in #9140 regarding unbounded caches.

Feel free to ignore if your specific case differs from these.

[aptor9]

This is what I got from claude. Maybe worth a double check?

Do I need garbage collect diagnostics or paths variables in lsp/client.ts?

● Looking at this code, there are two data structures that accumulate state:

1. diagnostics (line 51) - Map<string, Diagnostic[]> - Stores diagnostics per file path
2. files (line 135-137) - { [path: string]: number } - Tracks document versions

Short answer: No, you likely don't need to.

Here's why:

1. Lifecycle is tied to the LSP client - Both maps are naturally garbage collected when the client calls shutdown() (line 239-245) and the client object is released.
2. diagnostics is self-updating - When the LSP server clears diagnostics for a file, it sends an empty array via publishDiagnostics, which updates the map correctly. It's also
   cleared on file open (line 194).
3. files versioning is needed - The version numbers must persist to correctly distinguish between didOpen vs didChange notifications. Clearing this could cause protocol issues
   if a file is re-opened (version conflicts).
4. Memory impact is minimal - These store string keys with small values (arrays or numbers). Even with hundreds of files, the memory footprint is negligible.

When you might want to consider it:

• If the LSP client lives for extremely long sessions with thousands of unique files being touched
• If you implement a textDocument/didClose notification (currently missing), you could clean up both maps when a file is explicitly closed

For typical usage patterns, the current design is fine.

[sauerdaniel]

This was already fixed in commit f936043 (Jan 15, 2026):

diagnostics.clear()
for (const path in files) delete files[path]

The fix is exactly as proposed in this issue. See: f936043