[Bug] LSP tool spawns new kotlin-lsp JVM per invocation without reuse or cleanup

Bug Description

# Claude Code bug report — kotlin-lsp JVM leak (draft to submit) Where to file: https://github.com/anthropics/claude-code/issues (search kotlin-lsp / "LSP leak" first — comment on an existing issue if one matches, else open a new one and paste the body below. If your Claude Code build has a /bug slash command, that's the fastest path — it auto-attaches version + env.) Filed-from context: IndyTools dev Mac, 2026-05-25. Mitigation tracked locally as FW-FORGE-LSP-HYGIENE-1. --- Title: Claude Code leaks a kotlin-lsp JVM per LSP tool call — no reuse or reap within a session Environment: - Claude Code CLI, macOS (Apple Silicon) - LSP backend: JetBrains kotlin-lsp 262.2310.0 (Homebrew) — a full IntelliJ-platform JVM - Large multi-module Maven/Kotlin project Summary: The LSP tool (findReferences, workspaceSymbol, etc.) spawns a new kotlin-lsp server process per invocation and never reuses or reaps prior instances within the same session. They accumulate as live children of the claude process (parent = the live claude PID, not 1 — so they're not "orphans"). Repro: 1. Open a large Kotlin project in Claude Code. 2. Use the LSP tool several times across a long session. 3. pgrep -fl kotlin-lsp → many instances, each a full IntelliJ-platform JVM, etimes spanning hours. Observed: 17 live kotlin-lsp JVMs under one claude PID (etimes 2–30h) in a ~day-long session. Expected: one long-lived kotlin-lsp server per workspace, reused across LSP calls in a session (as an editor does), torn down on session exit. Actual: N instances accumulate; each re-indexes the whole multi-module reactor. Collectively they cause memory pressure and LSP flakiness — "can't connect to daemon" errors and empty/partial findReferences (querying an instance still cold-indexing, or a starved/half-dead one). False-empty findReferences is especially dangerous: it silently under-reports during a rename refactor. Impact: LSP code-intelligence becomes unreliable mid-session; the machine accumulates GBs of idle JVMs. Suggested fix: cache and reuse a single kotlin-lsp connection per workspace per session; reap on session exit and/or idle timeout. (Orphaned ppid=1 instances from dead sessions are a related secondary leak, but in-session reuse is the core fix.) Workaround: pkill -f kotlin-lsp (Claude Code respawns one on demand).

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.150
• Feedback ID: 7edc9fa0-4ad5-4553-b57b-d14b8ace00f7

Errors

[]