Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Kotlin LSP spawns unbounded number of processes — 127+ instances consuming 35GB RAM [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47085•Fetched 2026-04-13 05:41:53
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
tstaplertstapler
Participants
github-actions[bot]github-actions[bot]tstaplertstapler
Timeline (top)
labeled ×5commented ×1

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.

Error Message

$ 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

Root Cause

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.

Fix Action

Workaround

pkill -f kotlin-lsp

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

Code Example

$ 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

---

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

---

pkill -f kotlin-lsp
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The issue can be temporarily mitigated by manually killing the orphaned kotlin-lsp processes using pkill -f kotlin-lsp, but a permanent fix requires addressing the process management issue in Claude Code's LSP integration.

Guidance

  • Investigate the Claude Code's LSP integration to determine why it is not reaping old kotlin-lsp processes, potentially due to a bug or misconfiguration.
  • Consider implementing a fixed pool of LSP server processes or a mechanism to kill old instances before spawning new ones.
  • Monitor system resources to detect similar issues and prevent system unresponsiveness or OOM risks.
  • Evaluate the --add-opens flags and other command-line arguments passed to the java command to ensure they are not contributing to the issue.

Example

No code snippet is provided as the issue is related to process management and not a specific code snippet.

Notes

The provided workaround using pkill -f kotlin-lsp is temporary and may not be suitable for production environments. A permanent fix requires addressing the underlying issue in Claude Code's LSP integration.

Recommendation

Apply workaround: Manually killing the orphaned kotlin-lsp processes using pkill -f kotlin-lsp can temporarily mitigate the issue, but it is essential to investigate and address the root cause to prevent similar issues in the future.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

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

#agent setup#task chaining#parallel task#integration issue#index setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Kotlin LSP spawns unbounded number of processes — 127+ instances consuming 35GB RAM [1 comments, 2 participants]