gopls-lsp plugin installed+enabled but missing lspServers wiring; LSP tool never available for Go

Summary

The official gopls-lsp plugin shows as installed and enabled, and gopls is correctly
installed and on PATH, but the built-in LSP tool it's supposed to back never becomes
available in any session — the plugin's installed package is missing the lspServers
wiring that the marketplace catalog says it has.

Environment

• Claude Code version: 2.1.258
• OS: Linux 6.17.0-1032-oem (Ubuntu)
• gopls: v0.23.0, resolved via $HOME/go/bin/gopls, confirmed on PATH
• Plugin: gopls-lsp@claude-plugins-official v1.0.0, installed 2026-08-17, marked

"enabledPlugins": {"gopls-lsp@claude-plugins-official": true} in
~/.claude/settings.json

What's broken

~/.claude/plugins/marketplaces/claude-plugins-official/.claude-plugin/marketplace.json
declares this plugin's language-server wiring:

{
  "name": "gopls-lsp",
  "source": "./plugins/gopls-lsp",
  "lspServers": {
    "gopls": {
      "command": "gopls",
      "extensionToLanguage": { ".go": "go" }
    }
  }
}

But the installed package at
~/.claude/plugins/cache/claude-plugins-official/gopls-lsp/1.0.0/.claude-plugin/plugin.json
does not carry this field at all:

{
  "name": "gopls-lsp",
  "description": "Go language server for code intelligence and refactoring",
  "version": "1.0.0",
  "author": { "name": "Anthropic", "email": "support@anthropic.com" }
}

And the marketplace's own source checkout for the plugin
(~/.claude/plugins/marketplaces/claude-plugins-official/plugins/gopls-lsp/) contains
only README.md and LICENSE — no .claude-plugin/plugin.json of its own. The
lspServers block appears to exist only as catalog/listing metadata in
marketplace.json (and the derived plugin-catalog-cache.json), and never gets written
into the plugin package that actually gets installed and loaded per session.

Net effect: the built-in LSP tool (operations findReferences, goToDefinition,
goToImplementation, documentSymbol, etc. — confirmed present in the installed CLI
binary itself) never has anything telling it to spawn gopls for .go files, so it
never appears as an available tool, in any session, regardless of working directory.

Steps to reproduce

1. Install/enable the official gopls-lsp plugin with gopls already on PATH.
2. Start a new session with cwd inside a real Go module (a directory with go.mod).
3. Ask Claude to find references to a symbol defined in that module, or explicitly ask

it to use the LSP tool.

Expected

The LSP tool is available and backed by gopls, per the plugin's stated purpose.

Actual

No LSP tool is ever offered — ToolSearch for LSP finds nothing, and when asked
directly to use it, the assistant reports:

There's no LSP tool available in this environment — my search turned up nothing matching (just unrelated browser/calendar/Compass tools). This session doesn't have a code-intelligence/LSP server configured for Go.

I confirmed across many sessions over several days (including ones with heavy .go file
reading in the correct working directory) that LSP is never invoked or even offered.

What I tried

I hand-patched the installed plugin.json to add the missing lspServers block
(matching the marketplace entry exactly), then tested in a brand-new session. No
change — LSP still isn't offered. This suggests the runtime resolves/caches this
plugin's server wiring at install time rather than reading the manifest fresh per
session, so whatever went wrong happened at install and isn't fixable by editing the
cached file after the fact — reinstalling the plugin doesn't help either since the same
broken package would presumably be fetched again.

Note

Across this machine's entire local session history I found exactly two genuine
invocations of the LSP tool, both from 2026-08-25 in a single session, both
unexplained by anything above — possibly a different resolved state at that time. I'm
including this for completeness but it doesn't change the diagnosis above, which is
based on the current, reproducible state.