1
00:00:00,000 --> 00:00:01,037
Welcome to the show!

2
00:00:01,037 --> 00:00:03,436
I'm Lachlan Reed with James Turner,

3
00:00:03,436 --> 00:00:08,182
and mate, I wanna start with a very
specific kind of misery: you're deep

4
00:00:08,182 --> 00:00:11,755
in a debugging loop,
you finally see the shape of the bug,

5
00:00:11,755 --> 00:00:15,516
you hit /resume on a big Claude Code
session...

6
00:00:15,516 --> 00:00:18,075
and then you just stare at a spinner for
15,

7
00:00:18,075 --> 00:00:19,035
20 seconds.

8
00:00:19,035 --> 00:00:22,479
On a session that's ballooned past 40
megabytes,

9
00:00:22,479 --> 00:00:26,132
it used to feel like waiting on a build
cache that forgot its job.

10
00:00:26,132 --> 00:00:27,596
That "40 megabytes" part matters.

11
00:00:27,596 --> 00:00:29,753
This isn't tiny-chat overhead.

12
00:00:29,753 --> 00:00:33,034
This is a real agentic session that's
been going for hours,

13
00:00:33,034 --> 00:00:36,156
maybe days, with tools, branches,

14
00:00:36,156 --> 00:00:37,277
retries, all of it.

15
00:00:37,277 --> 00:00:42,064
And in those workflows, 15 to 20 seconds
is long enough to lose the exact

16
00:00:42,064 --> 00:00:44,957
stack frame you were holding in your
head.

17
00:00:42,064 --> 00:00:44,957
Exactly.

18
00:00:44,957 --> 00:00:48,637
It's not just waiting -- it's momentum
leakage.

19
00:00:48,637 --> 00:00:52,660
I've had that thing where I'm halfway
back into a nasty frontend state

20
00:00:52,660 --> 00:00:57,717
bug, then the tool pauses, and my brain
just wanders off like a roo through

21
00:00:57,717 --> 00:00:58,878
a busted fence.

22
00:00:58,878 --> 00:01:08,861
Version 2.

23
00:00:58,878 --> 00:01:08,861
1.116 targets THAT pain: /resume is now
up to 67% faster on

24
00:01:08,861 --> 00:01:13,204
large sessions.Up to 67% faster
is a chunky number.

25
00:01:13,204 --> 00:01:16,158
So what changed -- was it compression,

26
00:01:16,158 --> 00:01:19,117
caching, what?

27
00:01:16,158 --> 00:01:19,117
Not magic, thankfully.

28
00:01:19,117 --> 00:01:22,882
Two pretty practical things: incremental
indexing,

29
00:01:22,882 --> 00:01:25,600
and skipping dead-fork entries during
startup.

30
00:01:25,600 --> 00:01:29,490
Incremental indexing means it doesn't
keep reprocessing the whole giant

31
00:01:29,490 --> 00:01:31,482
session from scratch every time.

32
00:01:31,482 --> 00:01:33,121
It updates what changed.

33
00:01:33,121 --> 00:01:38,003
Much saner.

34
00:01:33,121 --> 00:01:38,003
And the "dead-fork entries" bit is the
part I think people

35
00:01:38,003 --> 00:01:40,445
won't get unless they've lived in these
tools.

36
00:01:40,445 --> 00:01:44,206
A fork here is basically a branch in the
agent's work history,

37
00:01:44,206 --> 00:01:44,528
right?

38
00:01:44,528 --> 00:01:47,165
Like, try one approach, then another,

39
00:01:47,165 --> 00:01:49,400
then abandon the first one.

40
00:01:47,165 --> 00:01:49,400
Yeah,

41
00:01:49,400 --> 00:01:50,120
that's it.

42
00:01:50,120 --> 00:01:53,321
Long sessions grow these abandoned side
roads.

43
00:01:53,321 --> 00:01:55,879
If your team leans hard on /branch,

44
00:01:55,879 --> 00:01:59,633
you can pile up loads of dead forks --
stuff that's no longer relevant,

45
00:01:59,633 --> 00:02:03,240
but still hanging around at startup like
old cables in the shed.

46
00:02:03,240 --> 00:02:07,498
So skipping those dead entries means less
junk to wade through before

47
00:02:07,498 --> 00:02:11,238
you're back in flow.Important
caveat,

48
00:02:11,238 --> 00:02:16,529
though: "40 megabytes and above." That
tells me this is a large-session

49
00:02:16,529 --> 00:02:20,641
optimization,
not some universal speed miracle.

50
00:02:16,529 --> 00:02:20,641
Spot on.

51
00:02:20,641 --> 00:02:25,285
If your sessions are small, you probably
won't feel a night-and-day change.

52
00:02:25,285 --> 00:02:29,505
But for the people with monster sessions
-- the ones living in long-running

53
00:02:29,505 --> 00:02:33,833
agent workflows -- this is the difference
between a tool that feels sticky

54
00:02:33,833 --> 00:02:36,477
and one that gets out of your
way.Okay,

55
00:02:36,477 --> 00:02:37,999
now the sharp edge.

56
00:02:37,999 --> 00:02:44,122
Before 2.

57
00:02:37,999 --> 00:02:44,122
1.116, a sandbox auto-allow rule like
Bash(rm:*) could create

58
00:02:44,122 --> 00:02:45,122
a nasty hole.

59
00:02:45,122 --> 00:02:50,007
It could auto-allow rm or rmdir against
dangerous targets -- slash,

60
00:02:50,007 --> 00:02:53,124
your home directory,
other critical system paths.

61
00:02:53,124 --> 00:02:55,203
That is not a theoretical paper cut.

62
00:02:55,203 --> 00:03:00,693
That is catastrophic if it fires.

63
00:02:55,203 --> 00:03:00,693
And "Bash(rm:*)" sounds so harmless

64
00:03:00,693 --> 00:03:01,797
when you're setting it up.

65
00:03:01,797 --> 00:03:03,835
Like, oh yeah, cleanup workflow,

66
00:03:03,835 --> 00:03:05,714
bin some temp files, no worries.

67
00:03:05,714 --> 00:03:09,395
But wildcard rules are slippery little
devils.

68
00:03:09,395 --> 00:03:11,712
You think you're giving the tool a broom,

69
00:03:11,712 --> 00:03:14,400
and suddenly it's got a bulldozer.

70
00:03:11,712 --> 00:03:14,400
Right.

71
00:03:14,400 --> 00:03:18,415
The core bug was that the dangerous-path
safety check could get bypassed

72
00:03:18,415 --> 00:03:20,880
when those auto-allow rules were in play.

73
00:03:20,880 --> 00:03:22,802
So if you had a runaway agent,

74
00:03:22,802 --> 00:03:26,625
or even a crafted tool call,
it could delete something that should have

75
00:03:26,625 --> 00:03:31,160
been absolutely off-limits.

76
00:03:26,625 --> 00:03:31,160
Let me try to say that back in plain
English:

77
00:03:31,160 --> 00:03:38,917
"allowed" was accidentally stronger than
"safe." And that's upside down.

78
00:03:31,160 --> 00:03:38,917
Exactly.

79
00:03:38,917 --> 00:03:44,156
In 2.

80
00:03:38,917 --> 00:03:44,156
1.116, the dangerous-path check becomes
the hard floor.

81
00:03:44,156 --> 00:03:46,798
Even if auto-allow is configured,

82
00:03:46,798 --> 00:03:48,236
that check still applies.

83
00:03:48,236 --> 00:03:52,073
So "allowed" no longer means "allowed to
be catastrophic."

84
00:03:52,073 --> 00:03:54,476
I'm gonna be the slight devil's advocate
here.

85
00:03:54,476 --> 00:03:59,030
Broad allow rules ARE a convenience win
in cleanup-heavy workflows.

86
00:03:59,030 --> 00:04:02,589
If you've got agents constantly removing
generated files,

87
00:04:02,589 --> 00:04:07,231
temp folders, test artifacts -- typing
through prompts every time is

88
00:04:07,231 --> 00:04:12,019
a drag.

89
00:04:07,231 --> 00:04:12,019
Sure, but you picked "rm" and "rmdir."
Those are the two commands

90
00:04:12,019 --> 00:04:13,913
where convenience should come SECOND.

91
00:04:13,913 --> 00:04:18,512
If the path is "/" or "$HOME," I do not
care how smooth your cleanup

92
00:04:18,512 --> 00:04:19,385
workflow is.

93
00:04:19,385 --> 00:04:22,875
The guardrail has to win.
Yeah,

94
00:04:22,875 --> 00:04:23,275
fair.

95
00:04:23,275 --> 00:04:26,473
Nobody wants the fastest path to becoming
unemployed.

96
00:04:26,473 --> 00:04:30,876
And this is one of those fixes where if
you notice it,

97
00:04:30,876 --> 00:04:34,411
that probably means you were depending on
a loophole you really shouldn't

98
00:04:34,411 --> 00:04:37,280
have been depending on.

99
00:04:34,411 --> 00:04:37,280
That's the right framing.

100
00:04:37,280 --> 00:04:39,597
This changes behavior for some setups,

101
00:04:39,597 --> 00:04:40,556
but on purpose.

102
00:04:40,556 --> 00:04:45,438
It closes a bypass that should never have
existed.

103
00:04:40,556 --> 00:04:45,438
The next batch is quieter,

104
00:04:45,438 --> 00:04:49,355
but honestly these are the ones that make
tooling feel less haunted.

105
00:04:49,355 --> 00:04:54,980
There was a frontmatter hook bug:
PostToolUse and PreToolUse hooks defined

106
00:04:54,980 --> 00:05:00,241
in CLAUDE.

107
00:04:54,980 --> 00:05:00,241
md or in agent frontmatter were silently
not firing when launched

108
00:05:00,241 --> 00:05:05,193
with claude --agent, even though they
worked in interactive sessions.

109
00:05:05,193 --> 00:05:08,207
"Silently not firing" is the bad phrase
there.

110
00:05:08,207 --> 00:05:10,407
Because if you're in headless CI,

111
00:05:10,407 --> 00:05:14,251
hooks are often doing the boring
important stuff -- logging,

112
00:05:14,251 --> 00:05:17,409
auditing, policy checks,
little guardrails.

113
00:05:17,409 --> 00:05:20,926
If those work interactively but not
through --agent,

114
00:05:20,926 --> 00:05:25,320
teams can think they have coverage when
they actually don't.

115
00:05:20,926 --> 00:05:25,320
Yep.

116
00:05:25,320 --> 00:05:26,840
False sense of safety.

117
00:05:26,840 --> 00:05:29,317
Which is worse than a loud failure,

118
00:05:29,317 --> 00:05:32,031
because a loud failure at least taps you
on the shoulder.

119
00:05:32,031 --> 00:05:38,569
This one just smiled and nodded.

120
00:05:32,031 --> 00:05:38,569
And the fix is mostly "no surprises."

121
00:05:38,569 --> 00:05:41,964
Interactive-session hook behavior stays
the same.

122
00:05:41,964 --> 00:05:45,241
What changes is the automation path now
lines up,

123
00:05:45,241 --> 00:05:50,420
which is exactly what you want from
consistency.

124
00:05:45,241 --> 00:05:50,420
There's also a nice MCP

125
00:05:50,420 --> 00:05:51,724
startup improvement.

126
00:05:51,724 --> 00:05:54,915
If you've got multiple stdio servers
configured,

127
00:05:54,915 --> 00:05:59,446
resources/templates/list used to get
fetched eagerly for every server

128
00:05:59,446 --> 00:06:00,272
at startup.

129
00:06:00,272 --> 00:06:05,756
Now it's deferred until the first
@-mention.

130
00:06:00,272 --> 00:06:05,756
That "first @-mention" detail

131
00:06:05,756 --> 00:06:06,636
is huge.

132
00:06:06,636 --> 00:06:09,833
It means don't load all the menus before
anyone's ordered dinner.

133
00:06:09,833 --> 00:06:12,790
If I'm not actually referencing a server
with @,

134
00:06:12,790 --> 00:06:16,804
don't make startup pay the tax.

135
00:06:12,790 --> 00:06:16,804
Beautifully put.

136
00:06:16,804 --> 00:06:20,319
Less eager fetching, less startup drag,

137
00:06:20,319 --> 00:06:23,442
especially in setups with a bunch of
servers hanging off the side.

138
00:06:23,442 --> 00:06:28,478
And one more tiny but real
quality-of-life fix: when gh commands hit

139
00:06:28,478 --> 00:06:33,451
GitHub API rate limits,
the Bash tool now surfaces a hint.

140
00:06:28,478 --> 00:06:33,451
Which sounds

141
00:06:33,451 --> 00:06:37,443
small until you've watched an agent bonk
into GitHub limits and keep retrying

142
00:06:37,443 --> 00:06:39,079
like it's headbutting a locked door.

143
00:06:39,079 --> 00:06:43,748
A surfaced hint gives it a chance to back
off instead of getting trapped

144
00:06:43,748 --> 00:06:48,103
in a dumb loopThat's the vibe of this
release for me: fewer invisible

145
00:06:48,103 --> 00:06:51,243
inconsistencies, fewer startup taxes,

146
00:06:51,243 --> 00:06:57,199
fewer "why is this flaky only in
automation?" moments.

147
00:06:51,243 --> 00:06:57,199
So if we zoom out,

148
00:06:57,199 --> 00:06:58,401
a couple caveats matter.

149
00:06:58,401 --> 00:07:03,222
The /resume speedup is most noticeable on
large sessions -- 40 megabytes

150
00:07:03,222 --> 00:07:03,602
and up.

151
00:07:03,602 --> 00:07:06,873
Smaller sessions are not suddenly
strapped to a rocket.

152
00:07:06,873 --> 00:07:09,750
This is a targeted fix for heavy users,

153
00:07:09,750 --> 00:07:13,119
not a universal turbo button.

154
00:07:09,750 --> 00:07:13,119
And on the safety side,

155
00:07:13,119 --> 00:07:15,518
there is a real behavior change.

156
00:07:15,518 --> 00:07:19,952
If somebody intentionally relied on
sandbox auto-allow bypassing the

157
00:07:19,952 --> 00:07:22,067
dangerous-path check...

158
00:07:22,067 --> 00:07:24,227
well, that door is shut now.

159
00:07:24,227 --> 00:07:25,745
Properly shut.

160
00:07:25,745 --> 00:07:29,520
Deadbolt on.Which I think is
good,

161
00:07:29,520 --> 00:07:31,840
but it does expose the bigger tension.

162
00:07:31,840 --> 00:07:36,806
People want AI coding tools to feel
frictionless: faster resumes,

163
00:07:36,806 --> 00:07:38,846
fewer prompts, less babysitting.

164
00:07:38,846 --> 00:07:42,925
That's the whole promise of agentic
workflows.

165
00:07:38,846 --> 00:07:42,925
But the more autonomous

166
00:07:42,925 --> 00:07:48,082
the tool gets, the less I want "she'll be
right" energy around rm and

167
00:07:48,082 --> 00:07:49,162
rmdir.

168
00:07:49,162 --> 00:07:50,564
Like, I love speed.

169
00:07:50,564 --> 00:07:51,363
I really do.

170
00:07:51,363 --> 00:07:54,077
I build products; I hate sluggishness.

171
00:07:54,077 --> 00:08:00,155
But some prompts are speed bumps in front
of a cliff.

172
00:07:54,077 --> 00:08:00,155
And the hooks fix

173
00:08:00,155 --> 00:08:02,364
kind of sits right in the middle of that
debate.

174
00:08:02,364 --> 00:08:04,439
Interactive behavior didn't change,

175
00:08:04,439 --> 00:08:05,723
which is nice and boring.

176
00:08:05,723 --> 00:08:10,310
But making --agent mode consistent means
your guardrails actually travel

177
00:08:10,310 --> 00:08:15,134
with the automation path instead of
evaporating when things go

178
00:08:10,310 --> 00:08:15,134
headless.

179
00:08:15,134 --> 00:08:16,759
That might be the whole story, actually.

180
00:08:16,759 --> 00:08:21,719
The best improvements here aren't just
"faster" or "safer." They're more

181
00:08:21,719 --> 00:08:22,999
PREDICTABLE.

182
00:08:22,999 --> 00:08:25,082
Resume does less useless work.

183
00:08:25,082 --> 00:08:27,402
Dangerous paths stay dangerous.

184
00:08:27,402 --> 00:08:33,124
Hooks fire where you thought they fired.

185
00:08:27,402 --> 00:08:33,124
So the open question I keep coming

186
00:08:33,124 --> 00:08:37,720
back to is this: if these tools keep
getting more autonomous,

187
00:08:37,720 --> 00:08:42,425
what do we value more when the two are in
tension -- fewer prompts and

188
00:08:42,425 --> 00:08:47,283
faster flow, or stricter always-on
guardrails even when they occasionally

189
00:08:47,283 --> 00:08:49,481
block the fastest path?Yeah.

190
00:08:49,481 --> 00:08:53,321
Because a tool that interrupts your flow
is annoying...

191
00:08:53,321 --> 00:08:57,721
but a tool that never interrupts itself
might be worse.

192
00:08:57,721 --> 00:09:00,282
Thanks for listening,
and we'll catch you next time.