Summary

agent/lsp/install.py::INSTALL_RECIPES uses @latest for some servers, e.g.:

agent/lsp/install.py:96:  "gopls": {"strategy": "go", "pkg": "golang.org/x/tools/gopls@latest", "bin": "gopls"},

When lsp.install_strategy: "auto" (the current default — separately tracked in #25015 as a defaults concern), the first edit of a Go file triggers go install golang.org/x/tools/gopls@latest, fetching whatever version the upstream registry currently serves. That is the same supply-chain hygiene gap that the rest of the codebase already addresses for application dependencies via pyproject.toml upper bounds.

The risk surface depends on the deployment posture (sandboxed worker, audited environment, etc.), but the fix is mechanical and consistent with how Hermes already handles its own runtime deps.

Locations

agent/lsp/install.py:50 — INSTALL_RECIPES table.

grep -n '@latest' agent/lsp/install.py

returns the unpinned recipes. Audit each.

Proposed fix

Pin every recipe to a specific verified version, with comments noting:

• The version pinned and date verified
• Any known CVE / security advisory bounded by deployment posture (e.g. gopls v0.21.x family — exploit gated on -listen / -port flags our default invocation does not pass)
• Upgrade cadence (manual review, similar to how pyproject.toml deps are handled)

Example shape:

"gopls": {"strategy": "go", "pkg": "golang.org/x/tools/gopls@v0.21.1", "bin": "gopls"},

Related

• lsp: opt-in defaults — enable + auto-install on first edit is too aggressive #25015 — opt-in defaults (orthogonal — pinning matters even when install becomes opt-in)
• lsp: idle subprocesses are never reaped — long-lived gateways accumulate ~200 MB per server forever #25016 — idle reaper (orthogonal)
• PR consolidation: fix 7 defects in PR #24168 LSP feature (orphan procs, patch_replace double-lint, opt-in defaults, +4 more) #24467 (defect D6) — original analysis by @scubamount, credited.

This issue exists so the pin work can be a small focused PR rather than part of a bundled rewrite.