Claude Code Fixes a 10GB MCP Leak and a Sneaky Resume Bug

Lachlan Reed

[warmly] Welcome to the show. James, I wanna start with the most cursed number in this whole update: 10 gigabytes of RSS. If you were running long Claude Code sessions before v2.1.132, especially chained to MCP servers over stdio, memory could quietly swell past 10GB and the whole thing would start feeling haunted.

James Turner

[questioning tone] Ten gigabytes of RSS is not "huh, maybe we should optimize later." That's "your laptop fan sounds like a drone and your agent dies at 2 a.m." So this was specifically stdio MCP, not HTTP MCP?

Lachlan Reed

[matter-of-fact] Exactly. And that distinction matters. This wasn't some broad Claude Code slowdown. The urgent fix in 2.1.132 was a stdio MCP memory leak. So if your workflow was the classic dev-tool chain -- Claude talking to local MCP servers over standard input and output -- the longer you let it run, the more likely it was to balloon, crash, or force a restart.

James Turner

[skeptical] I wanna underline the "longer you let it run" part. Because for a five-minute prompt session, you might never notice. But if you're doing the thing everybody actually wants -- multi-hour automation, repo work, CI-ish chores, plan-execute loops -- then that leak becomes a production reliability problem, not a weird edge case.

Lachlan Reed

Yeah, dead right. It's the difference between a demo and a shift worker. In the shed, if my old trail bike leaks a drop of oil while idling, eh, maybe fine. If it leaks all day on a ride, you're walking home. Same here. Before 2.1.132, the practical workaround was session restarts. You'd basically treat restart as maintenance.

James Turner

"Treat restart as maintenance" is such a brutal sentence. [dryly] Like emptying a bucket under a leaky roof. And after 2.1.132, the point is not "we reduced memory a bit." The point is the leak is actually patched, so the restart ritual goes away.

Lachlan Reed

That's the story. The fix removes a behaviour teams had to design around. If your automation only worked because someone knew to bounce the session every so often, that's not robust. After this patch, that specific workaround disappears because the underlying leak is fixed.

James Turner

Let me try to explain the stdio-versus-HTTP angle back to you. [hesitates] Is the idea basically that stdio integrations were uniquely exposed because they stay glued to the process pipes in this long-lived way, while HTTP servers sit behind request-response boundaries that didn't hit the same leak path?

Lachlan Reed

[curious] Yeah, that's the useful way to think about it. Not that HTTP is magically perfect -- just that this bug lived in the stdio MCP path, and HTTP-based MCP servers were not exposed to the same leak. So if one team said, "we never saw it," and another said, "our sessions swell until they keel over," that could just be the transport choice.

James Turner

Transport choice. That's the memorable bit for me. Same tool, same model, different plumbing, wildly different operational pain. That's such an infrastructure story.

James Turner

The part that really says "this tool is growing up," though, is the env vars. v2.1.132 now injects CLAUDE_CODE_SESSION_ID into every Bash subprocess. [short pause] It now injects it everywhere Bash goes.

Lachlan Reed

[laughs] Mate, even a kangaroo could trip over fresh env var names. But yes -- CLAUDE_CODE_SESSION_ID. And the nice bit is scripts can now self-identify the Claude session that spawned them without you manually plumbing that value through every wrapper and shell script.

James Turner

That "without manual plumbing" part is huge. If every Bash subprocess gets the same stable session handle, you can log session-aware events, correlate telemetry, tag CI runs, build audit trails -- all off one ID. You stop guessing which shell action belonged to which Claude session.

Lachlan Reed

And that's one of those changes that sounds tiny if you're just prompting in a terminal. But once Claude's kicking off real scripts, a session ID is gold. You can stick that ID into logs, into build metadata, into whatever observability stack you've got. Suddenly the trail isn't just "something happened." It's "this Claude session caused THAT change."

James Turner

[responds quickly] Right -- "this Claude session." That's the exact trust boundary. If a CI run fails at 14:03 and the log line carries CLAUDE_CODE_SESSION_ID, you can correlate the failure, the shell command, and the agent session. That's not cosmetic. That's accountability.

Lachlan Reed

And the other env var is the total opposite kind of maturity. CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 lets teams opt out of the fullscreen renderer when Claude Code is running in places that mangle alternate screen mode -- CI, Jupyter terminals, tmux setups, all those weird and wonderful terminals that don't quite behave.

James Turner

[amused] One env var helps you trace automation. The other helps you SURVIVE automation. That's such a clean contrast. Session ID for observability; disable alternate screen so your terminal doesn't go weird and eat the interface.

Lachlan Reed

Yeah, and if you've ever had a terminal app misbehave in tmux, you know the feeling. It's like trying to read a map while someone's folding it shut. Alternate screen is lovely when it works. In the wrong environment, it's an absolute dog's breakfast. So having =1 there as an escape hatch matters.

James Turner

And I think this is the emotional shift with agent tools. Early on, you care about prompts and outputs. Later, you start caring about session handles, terminal modes, subprocess inheritance. That's when a tool becomes, like you said, production-shaped. It has to fit real systems, not just impress you in a demo.

Lachlan Reed

[reflective] That's the phrase, hey. Production-shaped. You don't ask for a session ID unless the thing is important enough to audit. You don't ask for a terminal mode switch unless the thing is embedded deep enough in your workflow that a broken screen redraw can ruin your day. Those are boring requests... until they're not.

Lachlan Reed

Then there's the sneaky one. Claude Code now correctly respects --permission-mode when resuming a plan-mode session with claude --resume. Before 2.1.132, that flag could be silently ignored.

James Turner

[sharply] "Silently ignored" is the scary phrase there. Not rejected. Not warned. Ignored. So the resumed session could come back with default permissions instead of the permissions you explicitly asked for?

Lachlan Reed

That's it. And on paper it sounds small -- a resume bug, a flag bug. But the practical effect is your intent gets undone. You thought you'd resumed with one permission setup; instead you got defaults. That's not just annoying. In the wrong repo, it's a safety issue.

James Turner

Let me make that concrete. If I'm resuming plan mode and I believe the repo is locked down -- maybe read-only, maybe constrained edit privileges -- but the resume comes back with defaults, then my mental model and the actual privileges no longer match. That's the kind of mismatch that causes one bad edit, one unexpected write, one "wait, why did it touch that file?"

Lachlan Reed

[matter-of-fact] Exactly. It's a trust bug wearing a tiny hat. Because the CLI accepted your flag, and you naturally assume the tool respected it. Most of us don't re-audit permissions every single resume. We just... carry on. That's where these bugs get you.

James Turner

I really like "trust bug wearing a tiny hat." [short pause] And the reason I think this matters beyond one release is that statefulness changes the stakes. Once a tool has sessions, resume paths, inherited env vars, permission modes -- all the little connective tissue -- then tiny defects in that tissue are not tiny anymore.

Lachlan Reed

Yeah. A stateless hiccup is often just a nuisance. A stateful hiccup can violate what you thought the system remembered about your choices. That's heavier. It's like saving a game, loading back in, and finding your safety settings reset. You don't say, "minor UI issue." You say, "hang on, can I trust the save?"

James Turner

And that's the lingering question I can't shake: as these tools get more stateful, how many resume bugs and environment bugs are really trust bugs in disguise? Because once an agent sits inside your real workflow, the difference between "default" and "what I explicitly asked for" is the whole ball game.

Lachlan Reed

[softly] Yeah. If the model is the brain, this release is about the plumbing -- memory, session identity, terminal behaviour, permissions. Not flashy. But when the plumbing fails, the whole house feels cursed. [warmly] Catch you next time.