[Feature Request] Add idle timeout configuration for LSP servers

Problem

LSP plugins (e.g. rust-analyzer, gopls, pyright) start a language server process when the LSP tool is first invoked in a session. The server then remains running for the entire lifetime of that Claude Code session, even if it is never used again.

In practice this means that if you open a Claude Code session in a Rust project, use a few LSP calls early on, then move on to other work or leave the session open in a terminal, rust-analyzer sits idle consuming significant RAM (often 1 - 4 GB+) and occasionally heavy CPU even when Claude is not actively in use. The same applies to other heavyweight language servers.

Since Claude Code sessions can remain open for hours or days - this leads to unnecessary resource consumption on developer machines.

Proposed solution

Add an optional idleTimeout field to the .lsp.json plugin configuration (and/or a global default in settings.json) that specifies how long (in milliseconds) an LSP server may be idle before Claude Code sends a shutdown/exit sequence and terminates the process.

Example .lsp.json:

{
"rust-analyzer": {
"command": "rust-analyzer",
"extensionToLanguage": {
".rs": "rust"
},
"idleTimeout": 1800000
}
}

Example global default in settings.json:

{
"lsp": {
"idleTimeout": 1800000
}
}

When the LSP tool is next invoked after an idle shutdown, Claude Code would restart the server transparently (as it already does on first use).

Alternatives considered

• Cron job to kill idle processes - works but is fragile and external to Claude Code. Users shouldn't need to manage LSP process lifecycles themselves.
• rust-analyzer server-side config - rust-analyzer has no idle exit option. The lifecycle is the client's (Claude Code's) responsibility per the LSP spec.
• Session-level idle timeout - Claude Desktop has a 300s session timeout (#23092) but that's a different concern. Individual LSP servers should be manageable independently.

Additional context

• Affects all LSP plugins, though heavier servers like rust-analyzer and Java/Kotlin LSPs make the impact most noticeable.
• The LSP spec's shutdown/exit sequence is already implemented in Claude Code (referenced in changelog fixes for strict servers rejecting null params), so the teardown path exists.
• startupTimeout is already a supported .lsp.json field, so idleTimeout would be a natural companion.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.77
• Feedback ID: c1659a4b-568c-4d2f-9aec-31fe521e5d18

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/samm/.local/share/claude/versions/2.1.77 (expected in multi-process scenarios)\n    at ovT (/$bunfs/root/src/entrypoints/cli.js:2648:2192)\n    at uxq (/$bunfs/root/src/entrypoints/cli.js:2648:1945)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-17T06:38:26.123Z"}]