CLAUDE LABJP
MEMORY — Claude Code closes a cluster of long-session memory leaks, including MCP stdio stderr piling up to 64 MB per server and LSP documents staying open indefinitelyTABLES — Very large markdown tables no longer stall rendering; tables over 200 rows now show the first 200 with a "… N more rows" noticeSPEED — Sessions carrying many deny/ask permission rules no longer lose seconds every turn: rule matchers are compiled once and cachedTOOLS — print/SDK sessions with many MCP tools get up to 7x faster tool rounds thanks to cached tool-pool assemblyARTIFACTS — Claude Code Artifacts turn session work into live, shareable web pages that update in place — useful for PR walkthroughs and dashboardsDEADLINE — Opus 4.7 fast mode is removed on July 24; speed: "fast" will error, so move to Opus 4.8 fast mode before thenMEMORY — Claude Code closes a cluster of long-session memory leaks, including MCP stdio stderr piling up to 64 MB per server and LSP documents staying open indefinitelyTABLES — Very large markdown tables no longer stall rendering; tables over 200 rows now show the first 200 with a "… N more rows" noticeSPEED — Sessions carrying many deny/ask permission rules no longer lose seconds every turn: rule matchers are compiled once and cachedTOOLS — print/SDK sessions with many MCP tools get up to 7x faster tool rounds thanks to cached tool-pool assemblyARTIFACTS — Claude Code Artifacts turn session work into live, shareable web pages that update in place — useful for PR walkthroughs and dashboardsDEADLINE — Opus 4.7 fast mode is removed on July 24; speed: "fast" will error, so move to Opus 4.8 fast mode before then
Articles/Claude Code
Claude Code/2026-07-16Advanced

Your Overnight Session Wakes Up at 3GB — Four Places Memory Piles Up, and How to Tell Them Apart

The Claude Code process I left running overnight had grown to 3.4GB of resident memory by morning. Here are the four accumulation sources closed in 2.1.209, how to separate what's left in your own setup by sampling RSS slope, and a watchdog pattern that folds a session before it hurts.

Claude Code192Memory3Long-running sessionsOperations10MCP43

Premium Article

I still remember the number I saw when I ran ps first thing that morning. The Claude Code process I had left running overnight was sitting at 3.4GB of resident memory. When I started it the night before, it had been in the 400MB range. The work itself had finished, and the output was fine. But the last stretch of turns had been visibly sluggish — each response took noticeably longer to come back.

For a while I filed this under "well, it ran a long time." When you run scheduled work as an indie developer, nobody is watching the night shift. You check the results in the morning and accept the slowness as the price of leaving something unattended.

Then I read through the memory-related fixes in 2.1.209 and 2.1.208. Four of them, and reading closely, that slowness wasn't one vague thing called "running long." It was four separate accumulations happening in four separate places for four separate reasons. And some of them, I had invited in myself.

It Wasn't Piling Up in One Place

The four fixes are different in kind. If you read them as a single "memory leaks fixed" line, you'll misjudge which one matters in your environment.

Source What was happening After the fix Setups it hits
MCP stdio server stderr Up to 64MB of output retained per server Retention capped Several homegrown MCP servers resident, logging to stderr
LSP documents Opened documents never released LRU capped at 50 Sweeping a large repo, opening many files in sequence
Async hook output Output lingered after backgrounding Released on backgrounding Hooks in place, long work pushed to the background
Tool results (headless / SDK) Large results accumulated without bound Accumulation capped claude -p or SDK runs where tools return long output

My setup matched three of the four. Two homegrown MCP servers resident, both streaming progress to stderr. Nightly work running through claude -p unattended. Hooks in the mix. The one that didn't apply was LSP, only because I keep the model scoped to a small slice of a single repo.

This is where the fork is. Take that one-line "memory leaks fixed" and split it into four against your own configuration. Then you have an expectation for how much should improve after updating — and when the measurement disagrees with the expectation, you know the remainder lives in your own design.

Check Your Version Before You Measure

Confirm what you're running before sampling anything. A baseline taken on a build without the fixes throws off every comparison that follows.

claude --version

The decision is simple.

Your version What to do
Before 2.1.208 Sample one night before updating. The delta is exactly what the four fixes bought you
2.1.208 / 2.1.209 or later Sample as is. If it still climbs, the remainder is your configuration

That one pre-update night is worth more than it looks. It turns "feels lighter after updating" into "growth went from 620 MB/h to 95 MB/h." The first is useless the next time things get heavy. The second is a baseline.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
Separate the four accumulation sources — MCP stdio stderr, LSP documents, async hook output, and tool results — so you can judge which ones your own setup actually invites
Take home a 50-line sampler that records RSS across the whole process tree plus an analyzer that reports growth in MB/h, so you diagnose with numbers instead of impressions
Apply a watchdog-plus-checkpoint pattern that folds an oversized session and resumes it, keeping unattended runs healthy through the night
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

Claude Code2026-06-27
Will It Stay Light When You Run It Unattended? Observing and Capping Claude Code's Long-Session Memory
How to keep long, unattended Claude Code sessions from slowly getting heavier — with a tiny ps-based RSS sampler, a rolling-baseline watchdog, and session segmentation, shown with working scripts and a before/after comparison.
Claude Code2026-06-27
When an OAuth Token Expires, Your Unattended Run Has Nowhere to Go — A Token-Lifecycle Design That Keeps Remote MCP Alive
Remote MCP connectors are authorized via OAuth, but access tokens are short-lived. Interactive sessions can re-authorize in a browser; an unattended scheduled run has nobody to click the dialog. Here is a token-lifecycle design that owns expiry and refreshes ahead of time.
Claude Code2026-06-21
When Claude Code Still Writes Stale Code With Context7 Installed — Verifying the Injection Actually Worked
You installed Context7 MCP, yet Claude returns code against a deprecated API. Most of the time the documentation injection silently no-ops. Here are field notes on a hook that detects misses, pinning doc versions, and a harness that checks generated code every time.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →