1
00:00:00,331 --> 00:00:01,040
Welcome to the show.

2
00:00:01,293 --> 00:00:07,837
James, I wanna start with the most cursed
number in this whole update: 10 gigabytes

3
00:00:07,944 --> 00:00:09,038
of RSS.

4
00:00:09,331 --> 00:00:14,716
If you were running long Claude Code
sessions before v2.1.132,

5
00:00:14,774 --> 00:00:21,753
especially chained to MCP servers over
stdio, memory could quietly swell past 10GB

6
00:00:21,793 --> 00:00:24,075
and the whole thing would start feeling
haunted.

7
00:00:25,000 --> 00:00:29,151
[questioning tone] Ten gigabytes of RSS is
not "huh, maybe we should optimize

8
00:00:29,218 --> 00:00:29,633
later."

9
00:00:29,761 --> 00:00:34,679
That's "your laptop fan sounds like a
drone and your agent dies at 2 a.m."

10
00:00:34,999 --> 00:00:40,114
So this was specifically stdio MCP, not
HTTP MCP?

11
00:00:41,492 --> 00:00:42,002
Exactly.

12
00:00:42,112 --> 00:00:44,598
And that distinction matters.

13
00:00:44,678 --> 00:00:47,798
This wasn't some broad Claude Code
slowdown.

14
00:00:47,838 --> 00:00:54,761
The urgent fix in 2.1.132 was a stdio MCP
memory leak.

15
00:00:54,841 --> 00:01:00,127
So if your workflow was the classic
dev-tool chain -- Claude talking to local MCP

16
00:01:00,187 --> 00:01:04,682
servers over standard input and output --
the longer you let it run,

17
00:01:04,722 --> 00:01:08,681
the more likely it was to balloon, crash,
or force a restart.

18
00:01:09,144 --> 00:01:12,799
I wanna underline the "longer you let it
run" part.

19
00:01:12,844 --> 00:01:16,367
Because for a five-minute prompt session,
you might never notice.

20
00:01:16,447 --> 00:01:21,044
But if you're doing the thing everybody
actually wants -- multi-hour automation,

21
00:01:21,116 --> 00:01:27,409
repo work, CI-ish chores, plan-execute
loops -- then that leak becomes a production

22
00:01:27,462 --> 00:01:32,118
reliability problem, not a weird edge case
Yeah, dead right.

23
00:01:32,251 --> 00:01:35,234
It's the difference between a demo and a
shift worker.

24
00:01:35,607 --> 00:01:40,351
In the shed, if my old trail bike leaks a
drop of oil while idling,

25
00:01:40,458 --> 00:01:41,550
eh, maybe fine.

26
00:01:41,790 --> 00:01:45,471
If it leaks all day on a ride, you're
walking home.

27
00:01:45,599 --> 00:01:46,511
Same here.

28
00:01:46,625 --> 00:01:51,227
Before 2.1.132, the practical workaround
was session restarts.

29
00:01:51,347 --> 00:01:54,108
You'd basically treat restart as
maintenance.

30
00:01:55,000 --> 00:02:00,079
"Treat restart as maintenance" is such a
brutal sentence.

31
00:02:00,486 --> 00:02:03,318
Like emptying a bucket under a leaky roof.

32
00:02:03,338 --> 00:02:08,196
And after 2.1.132, the point is not "we
reduced memory a bit."

33
00:02:08,316 --> 00:02:13,634
The point is the leak is actually patched,
so the restart ritual goes away.

34
00:02:14,000 --> 00:02:15,122
That's the story.

35
00:02:15,222 --> 00:02:18,567
The fix removes a behaviour teams had to
design around.

36
00:02:18,860 --> 00:02:23,287
If your automation only worked because
someone knew to bounce the session every so

37
00:02:23,327 --> 00:02:25,127
often, that's not robust.

38
00:02:25,287 --> 00:02:31,124
After this patch, that specific workaround
disappears because the underlying leak is

39
00:02:31,191 --> 00:02:31,606
fixed.

40
00:02:32,000 --> 00:02:36,722
Let me try to explain the
stdio-versus-HTTP angle back to you.

41
00:02:37,576 --> 00:02:42,716
Is the idea basically that stdio
integrations were uniquely exposed because they

42
00:02:42,764 --> 00:02:48,078
stay glued to the process pipes in this
long-lived way, while HTTP servers sit

43
00:02:48,135 --> 00:02:52,152
behind request-response boundaries that
didn't hit the same leak path?

44
00:02:53,192 --> 00:02:55,080
Yeah, that's the useful way to think about
it.

45
00:02:55,240 --> 00:03:01,239
Not that HTTP is magically perfect -- just
that this bug lived in the stdio MCP

46
00:03:01,319 --> 00:03:06,440
path, and HTTP-based MCP servers were not
exposed to the same leak.

47
00:03:06,680 --> 00:03:12,112
So if one team said, "we never saw it,"
and another said, "our sessions swell until

48
00:03:12,144 --> 00:03:15,393
they keel over," that could just be the
transport choice.

49
00:03:16,000 --> 00:03:17,198
Transport choice.

50
00:03:17,374 --> 00:03:19,438
That's the memorable bit for me.

51
00:03:19,614 --> 00:03:25,433
Same tool, same model, different plumbing,
wildly different operational pain.

52
00:03:25,561 --> 00:03:27,907
That's such an infrastructure story.

53
00:03:28,000 --> 00:03:31,763
The part that really says "this tool is
growing up," though,

54
00:03:31,816 --> 00:03:33,202
is the env vars.

55
00:03:33,562 --> 00:03:40,559
v2.1.132 now injects
CLAUDE_CODE_SESSION_ID into every Bash

56
00:03:40,632 --> 00:03:41,802
subprocess.

57
00:03:42,022 --> 00:03:44,962
[short pause] It now injects it everywhere
Bash goes.

58
00:03:46,816 --> 00:03:50,882
Mate, even a kangaroo could trip over
fresh env var names.

59
00:03:50,982 --> 00:03:52,162
But yes --

60
00:03:52,215 --> 00:04:04,304
CLAUDE_CODE_SESSION_ID.

61
00:04:04,307 --> 00:04:08,715
And the nice bit is scripts can now
self-identify the Claude session that spawned

62
00:04:08,747 --> 00:04:13,275
them without you manually plumbing that
value through every wrapper and shell

63
00:04:13,332 --> 00:04:13,754
script.

64
00:04:14,000 --> 00:04:17,034
That "without manual plumbing" part is
huge.

65
00:04:17,221 --> 00:04:20,949
If every Bash subprocess gets the same
stable session handle,

66
00:04:20,989 --> 00:04:25,273
you can log session-aware events,
correlate telemetry, tag CI runs,

67
00:04:25,340 --> 00:04:27,834
build audit trails -- all off one ID.

68
00:04:27,974 --> 00:04:31,435
You stop guessing which shell action
belonged to which Claude session.

69
00:04:32,000 --> 00:04:35,925
And that's one of those changes that
sounds tiny if you're just prompting in a

70
00:04:35,978 --> 00:04:36,482
terminal.

71
00:04:36,662 --> 00:04:41,123
But once Claude's kicking off real
scripts, a session ID is gold.

72
00:04:41,263 --> 00:04:46,399
You can stick that ID into logs, into
build metadata, into whatever observability

73
00:04:46,452 --> 00:04:47,278
stack you've got.

74
00:04:47,394 --> 00:04:51,286
Suddenly the trail isn't just "something
happened."

75
00:04:51,393 --> 00:04:55,448
It's "this Claude session caused THAT
change."

76
00:04:56,000 --> 00:04:58,162
[responds quickly] Right -- "this Claude
session."

77
00:04:58,226 --> 00:04:59,998
That's the exact trust boundary.

78
00:05:00,131 --> 00:05:05,997
If a CI run fails at 14:03 and the log
line carries CLAUDE_CODE_SESSION_ID,

79
00:05:05,997 --> 00:05:05,997
you can correlate the failure, the shell
command, and the agent session.

80
00:05:05,997 --> 00:05:05,997
That's not cosmetic.

81
00:05:05,997 --> 00:05:05,997
That's accountability.

82
00:18:30,000 --> 00:18:33,680
And the other env var is the total
opposite kind of maturity.

83
00:18:33,893 --> 00:18:40,394
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1
lets teams opt out of the fullscreen renderer

84
00:18:40,474 --> 00:18:45,909
when Claude Code is running in places that
mangle alternate screen mode -- CI,

85
00:18:45,989 --> 00:18:51,192
Jupyter terminals, tmux setups, all those
weird and wonderful terminals that don't

86
00:18:51,259 --> 00:18:52,234
quite behave.

87
00:18:54,278 --> 00:18:56,633
One env var helps you trace automation.

88
00:18:56,773 --> 00:18:59,904
The other helps you SURVIVE automation.

89
00:19:00,032 --> 00:19:02,066
That's such a clean contrast.

90
00:19:02,166 --> 00:19:07,188
Session ID for observability; disable
alternate screen so your terminal doesn't go

91
00:19:07,241 --> 00:19:08,786
weird and eat the interface.

92
00:19:09,000 --> 00:19:12,678
Yeah, and if you've ever had a terminal
app misbehave in tmux,

93
00:19:12,698 --> 00:19:13,558
you know the feeling.

94
00:19:13,851 --> 00:19:17,155
It's like trying to read a map while
someone's folding it shut.

95
00:19:17,251 --> 00:19:19,876
Alternate screen is lovely when it works.

96
00:19:20,063 --> 00:19:23,640
In the wrong environment, it's an absolute
dog's breakfast.

97
00:19:23,907 --> 00:19:27,166
So having =1 there as an escape hatch
matters.

98
00:19:28,000 --> 00:19:30,802
And I think this is the emotional shift
with agent tools.

99
00:19:30,922 --> 00:19:34,002
Early on, you care about prompts and
outputs.

100
00:19:34,149 --> 00:19:38,556
Later, you start caring about session
handles, terminal modes,

101
00:19:38,621 --> 00:19:40,155
subprocess inheritance.

102
00:19:40,235 --> 00:19:43,352
That's when a tool becomes, like you said,
production-shaped.

103
00:19:43,485 --> 00:19:47,191
It has to fit real systems, not just
impress you in a demo.

104
00:19:48,138 --> 00:19:49,041
That's the phrase, hey.

105
00:19:49,092 --> 00:19:50,165
Production-shaped.

106
00:19:50,365 --> 00:19:54,646
You don't ask for a session ID unless the
thing is important enough to audit.

107
00:19:54,806 --> 00:19:59,204
You don't ask for a terminal mode switch
unless the thing is embedded deep enough in

108
00:19:59,236 --> 00:20:03,362
your workflow that a broken screen redraw
can ruin your day.

109
00:20:03,509 --> 00:20:06,722
Those are boring requests...

110
00:20:06,789 --> 00:20:07,765
until they're not.

111
00:20:08,000 --> 00:20:09,278
Then there's the sneaky one.

112
00:20:09,404 --> 00:20:14,398
Claude Code now correctly respects
--permission-mode when resuming a plan-mode

113
00:20:14,448 --> 00:20:16,240
session with claude --resume.

114
00:20:16,411 --> 00:20:21,359
Before 2.1.132, that flag could be
silently ignored.

115
00:20:22,273 --> 00:20:25,001
"Silently ignored" is the scary phrase
there.

116
00:20:25,111 --> 00:20:26,159
Not rejected.

117
00:20:26,199 --> 00:20:26,882
Not warned.

118
00:20:27,122 --> 00:20:28,242
Ignored.

119
00:20:28,589 --> 00:20:32,410
So the resumed session could come back
with default permissions instead of the

120
00:20:32,450 --> 00:20:34,251
permissions you explicitly asked for?

121
00:20:35,000 --> 00:20:35,641
That's it.

122
00:20:35,841 --> 00:20:40,272
And on paper it sounds small -- a resume
bug, a flag bug.

123
00:20:40,572 --> 00:20:45,674
But the practical effect is your intent
gets undone.

124
00:20:45,844 --> 00:20:51,400
You thought you'd resumed with one
permission setup; instead you got defaults.

125
00:20:51,672 --> 00:20:53,798
That's not just annoying.

126
00:20:53,985 --> 00:20:56,518
In the wrong repo, it's a safety issue.

127
00:20:57,000 --> 00:20:58,118
Let me make that concrete.

128
00:20:58,331 --> 00:21:04,515
If I'm resuming plan mode and I believe
the repo is locked down -- maybe read-only,

129
00:21:04,555 --> 00:21:09,239
maybe constrained edit privileges -- but
the resume comes back with defaults,

130
00:21:09,335 --> 00:21:13,881
then my mental model and the actual
privileges no longer match.

131
00:21:13,961 --> 00:21:19,079
That's the kind of mismatch that causes
one bad edit, one unexpected write,

132
00:21:19,179 --> 00:21:21,318
one "wait, why did it touch that file?"

133
00:21:22,560 --> 00:21:22,884
Exactly.

134
00:21:22,964 --> 00:21:24,884
It's a trust bug wearing a tiny hat.

135
00:21:25,044 --> 00:21:30,562
Because the CLI accepted your flag, and
you naturally assume the tool respected it.

136
00:21:30,722 --> 00:21:34,083
Most of us don't re-audit permissions
every single resume.

137
00:21:34,163 --> 00:21:35,282
We just...

138
00:21:35,335 --> 00:21:35,920
carry on.

139
00:21:36,080 --> 00:21:37,840
That's where these bugs get you.

140
00:21:38,000 --> 00:21:41,119
I really like "trust bug wearing a tiny
hat."

141
00:21:41,839 --> 00:21:45,841
[short pause] And the reason I think this
matters beyond one release is that

142
00:21:45,921 --> 00:21:48,003
statefulness changes the stakes.

143
00:21:48,211 --> 00:21:53,204
Once a tool has sessions, resume paths,
inherited env vars,

144
00:21:53,269 --> 00:21:57,845
permission modes -- all the little
connective tissue -- then tiny defects in that

145
00:21:57,914 --> 00:21:59,848
tissue are not tiny anymore.

146
00:22:01,000 --> 00:22:01,600
Yeah.

147
00:22:01,700 --> 00:22:04,198
A stateless hiccup is often just a
nuisance.

148
00:22:04,478 --> 00:22:09,243
A stateful hiccup can violate what you
thought the system remembered about your

149
00:22:09,313 --> 00:22:09,963
choices.

150
00:22:10,139 --> 00:22:11,483
That's heavier.

151
00:22:11,696 --> 00:22:16,276
It's like saving a game, loading back in,
and finding your safety settings reset.

152
00:22:16,476 --> 00:22:19,399
You don't say, "minor UI issue."

153
00:22:19,479 --> 00:22:22,278
You say, "hang on, can I trust the save?"

154
00:22:23,000 --> 00:22:28,194
And that's the lingering question I can't
shake: as these tools get more stateful,

155
00:22:28,234 --> 00:22:33,797
how many resume bugs and environment bugs
are really trust bugs in disguise?

156
00:22:33,827 --> 00:22:37,712
Because once an agent sits inside your
real workflow, the difference between

157
00:22:37,792 --> 00:22:41,792
"default" and "what I explicitly asked
for" is the whole ball game.

158
00:22:42,269 --> 00:22:42,401
Yeah.

159
00:22:42,668 --> 00:22:47,834
If the model is the brain, this release is
about the plumbing -- memory,

160
00:22:47,884 --> 00:22:50,704
session identity, terminal behaviour,
permissions.

161
00:22:50,904 --> 00:22:52,147
Not flashy.

162
00:22:52,347 --> 00:22:57,016
But when the plumbing fails, the whole
house feels cursed.

163
00:22:58,423 --> 00:22:59,098
Catch you next time.