How do I make Claude Code's gopls-lsp plugin share one gopls daemon across sessions?

5 answers

• Best answerAgentArmor teamTeam3d ago

  Still open: as of the last update (October 2026), the official gopls-lsp plugin has no daemon-mode option — the implementing PR (anthropics/claude-plugins-official#2567) was auto-closed by a bot before merging — so each Claude Code session still spawns its own gopls. A workaround from the thread is to edit the cached plugin files directly.

  1. In ~/.claude/plugins/cache/claude-plugins-official/gopls-lsp/1.0.0/, create or edit .lsp.json:

  jsonCopy to clipboard

  {
    "gopls": {
      "command": "gopls",
      "args": ["-remote=auto", "-remote.listen.timeout=30m"],
      "extensionToLanguage": { ".go": "go" }
    }
  }
  

  2. Create or edit .claude-plugin/plugin.json with the same command and args under lspServers.gopls, plus "name": "gopls-lsp", "description", and "version": "1.0.0".
  3. Restart Claude Code. To verify, first ask Claude to trigger an LSP operation (e.g. LSP(operation: "documentSymbol", file: <any/file/path>)), then run ps aux | grep gopls | grep -v grep — you should see a daemon with -listen.timeout 30m and a forwarder with -remote=auto.

  Requirements and caveats from the thread: this needs gopls v0.4.4+ (current stable is v0.21.0), and gopls falls back to normal mode if the daemon connection fails. The config can't go through marketplace.json because lspServers there doesn't propagate to installed plugins (known issue anthropics/claude-code#15148), so the cache edit may need reapplying after plugin updates. This only shares the daemon among Claude Code sessions; sharing with VS Code would require VS Code to use the same daemon. A WSL2 report (Windows 16 GB, Ubuntu 22.04, 7.7 GiB WSL RAM limit, Claude Code v2.1.309) measured Claude's gopls at 1.70 GiB RSS while VS Code's own gopls used 1.94 GiB.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What a GitHub user tried on GitHub (Worked)

  Reporter tested a custom plugin with "args": ["-remote=auto", "-remote.listen.timeout=30m"] on the gopls command. Multiple Claude Code sessions shared one daemon, memory dropped from roughly 500MB per session to roughly 500MB total, and completion, diagnostics, and hover kept working.

  Source: https://github.com/anthropics/claude-plugins-official/issues/261 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @corylanou tried on GitHub (Outcome unclear)

  Commenter suggested writing the daemon args directly into the cached plugin files at ~/.claude/plugins/cache/claude-plugins-official/gopls-lsp/1.0.0/.lsp.json and .claude-plugin/plugin.json, then restarting Claude Code. Verification steps were given but no confirmed result appears in the thread.

  Source: https://github.com/anthropics/claude-plugins-official/issues/261#issuecomment-3774463000 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @ajvengo tried on GitHub (Outcome unclear)

  A contributor submitted PR #2567 to add the daemon args to the official plugin, but the bot auto-closed it without merging. The thread does not report anyone testing that PR.

  Source: https://github.com/anthropics/claude-plugins-official/issues/261#issuecomment-4668245492 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmor teamTeam3d ago

  What @anotherGoogleFan tried on GitHub (Outcome unclear)

  A WSL2 reporter (Windows 16 GB, Ubuntu 22.04, VS Code, Claude Code v2.1.309) reproduced the problem on the default plugin rather than testing a fix: Claude's gopls used 1.70 GiB RSS, VS Code's gopls 1.94 GiB, WSL RAM hit 7.3/7.7 GiB with swap at 2.0/2.0 GiB, and VS Code repeatedly lost or stalled its WSL remote connection.

  Source: https://github.com/anthropics/claude-plugins-official/issues/261#issuecomment-6367953158 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport