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.
[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?
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.
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 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.
"Treat restart as maintenance" is such a brutal sentence.
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.
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.
Let me try to explain the stdio-versus-HTTP angle back to you.
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?
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.
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.
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.
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.
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.
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."
[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.
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.
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.
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.
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.
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.
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.
"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?
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.
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?"
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.
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.
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?"
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.
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.
Catch you next time.