Claude Code's gopls Integration Was Eating 30GB of My RAM

Overview

After upgrading to a new Mac Studio with 128GB of RAM, I was still experiencing memory pressure issues. The culprit? Claude Code was launching a separate gopls instance for every session - and with 40+ sessions open, that adds up fast.

The Problem

I recently bought a Mac Studio with 128GB of RAM, thinking it would solve all my memory problems. I do a lot of AI coding with multiple sessions open simultaneously. But within three days, I was hitting memory pressure issues again.

What is gopls?

For those unfamiliar, gopls is the official Go language server. Claude Code recently integrated LSP (Language Server Protocol) support, which allows it to quickly and accurately parse Go code. This was a fantastic addition - I noticed immediate improvements in how Claude navigated and understood Go code.

The problem? Claude Code launches a separate gopls instance for every single Claude session.

The Math Doesn't Work

Let me break down what was happening:

• Each gopls instance uses 500-800MB of RAM
• I typically have 5-10 projects open
• Within each project, I might have 5-10 Claude instances running
• At any given time, I had 40+ sessions open

That's potentially 20-30GB of RAM just for gopls instances.

I use TMUX and leave sessions running throughout the day and week, coming back to them as needed. I don't run an IDE - everything is at the CLI using Ghostty and TMUX. This workflow is designed to be low memory, so having gopls eat up that much RAM was unacceptable.

The Solution: Daemon Mode

The gopls team released daemon mode somewhat recently. Instead of launching a separate server for each connection, daemon mode allows one gopls instance to serve multiple clients.

I tried configuring this locally by: 1. Disabling Claude's built-in gopls plugin 2. Enabling my own daemon-mode configuration

Initially, it didn't work. After much investigation with Claude's help (using my /start-issue skill), we discovered that:

1. The fix needed to be in the Claude plugins official repo
2. Internal plugins, including gopls, are developed and maintained by Anthropic
3. External PRs are auto-closed, but issues can be filed

The Workaround

Until Anthropic updates the official plugin, I modified my local copy of their plugin to use daemon mode. Yes, this gets overwritten when Claude updates, but it solves my immediate problem.

The key change is simple - instead of running gopls serve for each session, use gopls -remote=auto which connects to a shared daemon.

Filing the Issue

I filed a detailed issue in the Claude plugins repository with: - Reproduction steps - Memory consumption data - The proposed solution - Proof that it works locally

I always try to do thorough research before filing issues. There's nothing more frustrating for maintainers than issues that recommend fixes that don't actually work technically.

Key Takeaways

1. Monitor your memory usage - Even with lots of RAM, poorly behaved tools can cause pressure
2. AI can help diagnose AI tools - I used Claude Code to figure out why Claude Code was eating my RAM
3. Work trees and TMUX enable massive parallelism - But that parallelism comes with resource costs
4. Daemon mode exists for a reason - Many LSPs support shared instances for exactly this use case

My Workflow

For context, here's how I work: - I run 10-20 concurrent Claude sessions across multiple projects - I use git worktrees to isolate different issues - TMUX lets me switch between sessions instantly - I have the Max plan and regularly approach its limits

This workflow is incredibly productive, but it requires careful resource management. If you're running multiple Claude sessions with Go projects, check your gopls processes - you might be surprised how much RAM they're consuming.