Hermes LSP diagnostics are useful, but the defaults now need an operator safety pass
Hermes' new LSP-backed edit diagnostics are moving quickly from feature to operations surface. Fresh issue #25015 says the subsystem currently ships enabled with `install_strategy: auto`, so the first Python, Go, Rust, or TypeScript edit in a git repo can silently install a language server into the Hermes home. Issue #25017 adds the supply-chain angle: some install recipes use moving `@latest` targets such as `golang.org/x/tools/gopls@latest`, which is awkward for audited or reproducible environments. Issue #25016 reports the resource side: the LSP manager defines a 600-second idle timeout but has no reaper, so long-running gateways can keep pyright, gopls, tsserver, or rust-analyzer processes alive indefinitely, adding roughly 80-300+ MB per language/workspace. PR #25021 adds the missing idle-subprocess reaper, while PR #25011 salvages two smaller LSP fixes: faster CLI gating for `hermes lsp` and avoiding false mutation-failure classification when diagnostics contain nested `error` keys.
This is the normal second-order cost of giving agents better coding feedback. Real language servers improve edits, but they also bring package installation, version drift, subprocess lifecycle, and memory ownership into the agent runtime. For teams, those are not minor implementation details; they decide whether a helpful diagnostic layer is safe to run unattended.
- Issue #25015 says LSP is enabled by default with install_strategy auto, allowing first edit to trigger language-server installation under HERMES_HOME/lsp/bin
- Issue #25017 points to unpinned recipes such as gopls@latest and frames them as a supply-chain hygiene gap
- Issue #25016 says idle LSP subprocesses are tracked but never reaped, with pyright around 200 MB, gopls around 80 MB, tsserver around 150 MB, and rust-analyzer above 300 MB
- PR #25021 adds an idle reaper loop and tests that stale clients are shut down while active clients remain
- PR #25011 includes the mutation-diagnostics false-positive fix for successful write_file / patch results with nested diagnostic errors
- Most items are open issues or PRs, so the final defaults may change before release
- Turning auto-install off protects audited environments but may make diagnostics appear unavailable until servers are installed manually
- Pinned recipes improve reproducibility but require a maintenance process for security updates