Kotlin LSP spawns unbounded number of processes — 127+ instances consuming 35GB RAM

Summary

Claude Code's Kotlin LSP integration leaks processes — it spawns a new kotlin-lsp JVM instance each time it performs an LSP operation but never reaps old ones. After a single working session, 127+ processes accumulated consuming ~35GB of RAM.

Environment

• Claude Code version: 2.1.104
• OS: Linux 6.6.128-1-MANJARO x86_64
• Kotlin LSP version: 262.2310.0 (via linuxbrew)
• Total RAM: 62 GB
• Session duration: ~4 hours of active development

Observed behavior

$ pgrep java | xargs -I{} ps -o pid,rss,cmd --no-headers -p {} | awk '/kotlin-lsp/{count++; rss+=$2} END{printf "Processes: %d, RSS: %.1f GB\n", count, rss/1024/1024}'
Processes: 127, RSS: 35.2 GB

All 127 processes are identical — same binary, same flags, all running:

/home/linuxbrew/.linuxbrew/Caskroom/kotlin-lsp/262.2310.0/jre/bin/java \
  [... many --add-opens flags ...] \
  com.jetbrains.ls.kotlinLsp.KotlinLspServerKt --stdio

Processes were spawned continuously throughout the session, starting at ~10:18 AM and still being created at 12:07 PM (verified via ps -o lstart). None were reaped.

Expected behavior

A fixed pool of LSP server processes (ideally 1–2), with old instances killed before spawning new ones.

Impact

• 35 GB of RAM consumed by orphaned LSP processes
• System becomes unresponsive / OOM risk on machines with less RAM
• Processes persist until manual pkill -f kotlin-lsp or system reboot

Workaround

pkill -f kotlin-lsp

Processes respawn when Claude Code's LSP integration re-activates.