clangd-lsp plugin starts an unbounded --background-index per session; memory grows to gigabytes and cannot be tuned

What happens. The official clangd-lsp@claude-plugins-official plugin launches clangd --background-index with no other arguments (lspServers.clangd.args in the marketplace entry). Every Claude Code session that touches a C/C++ file starts its own clangd, and each indexes the whole compilation database in the background with no memory or worker limit.

Measured (Windows 11, clangd 22.1.3, a large CMake C++ project, two concurrent sessions). One clangd reached 3.1 GB working set after 25 minutes and was still growing (3.4 GB half an hour later); another held 0.9 GB after 40 minutes. A third, from the same plugin, was killed by hand at about 15 GB after several hours. The parent of each was a claude.exe session, so N sessions mean N independent indexers.

Why it is a problem. The index lives per process in memory (ASTs, preambles, PCH) even though the on-disk index is shared, so concurrent sessions multiply the cost. There is no way to pass arguments (-j, --pch-storage=disk, --background-index=false) without replacing the plugin: the arguments live in the marketplace manifest, which an update overwrites, and the installed package's plugin.json carries no lspServers.

Workaround we use. A local plugin with --background-index=false --pch-storage=disk -j=2 and the official one disabled: 146-257 MB per session instead of gigabytes.

Request.

1. Ship the plugin with bounded defaults (no or low-priority background index, PCH on disk, capped workers), or
2. let settings.json override lspServers.<name>.args for an installed plugin, and
3. ideally stop an idle language server after a configurable timeout.

Related but different: #90114 / #84857 (missing lspServers in the installed package), #40282 (more LSP operations).