Welcome to the show - James, I need to start with one tiny config flag
that is absolutely not tiny in practice: in Claude Code v2.
1.121,
you can puton an MCP server entry inor,
and that means the server's tools load at session START instead of waiting
for tool-search to wake them up. v2.
1.121 and one boolean --
that's the kind of release note people skip,
and then three weeks later they're like,
"why does my workflow suddenly feel better?" Because timing matters.
If the tool enters on turn one instead of turn six,
the whole conversation shape changes.
Exactly.
And the pain it's solving is super ordinary.
You've got the same Postgres server,
same internal API helper, same CI helper.
Every session.
But because of deferral, you sort of end up nudging Claude like you're
introducing two mates at a barbie - "nah, use THAT one, the database one,
the one we've used all week."
It feels a bit silly.Okay,
but the deferral existed for a reason.
If you've got, say, 30-plus tools sitting behind a giant MCP catalog,
loading all of that up front is how you quietly torch context before
the first useful answer.
That's not paranoia - that's just budgeting.
Tokens spent early are still tokens gone.
Right,
and that's the distinction people have gotta keep straight:is NOT "turn off
deferral everywhere."
It's per server.
That's the whole trick.
You leave the weird exploratory servers lazy-loaded,
and you pin the two or three workhorse servers you touch constantly.
Per-server
is the important phrase there.
Not global.
So let me try to explain it back: if I have one MCP server for
my everyday Postgres queries and another for some giant rarely-used internal
docs system, I can seton the Postgres one,
but keep the docs server deferred until tool-search actually needs it?
Yep
- that's it.
Almost like pinning your favorite spanner on the pegboard and leaving
the rest in the drawer.
The good stuff is in reach, the clutter stays out of the way.
And because you can put it in the project-levelor the user-level,
you've got a nice split between team defaults and your own personal setup.
Thatversussplit
is actually bigger than it sounds.
Project-level means a team can decide,
"our internal API server is mission-critical,
load it every time." User-level
means I can keep my own weird toolbox without forcing it on everyone
else.
Yeah, and that's where this stops being a nerdy config footnote and becomes
workflow design.
In my web-dev world, the annoying part isn't just waiting - it's
context-switching.
If I'm halfway through tracing a bug and Claude still hasn't got the
DB tool in play, I have to interrupt the task to steer it.
That's friction.
Tiny friction, but it stacks up like sawdust in the shed.
And I think
the counterpoint is healthy: if you load 30 tools because "maybe I'll need them,"
you've recreated the worst kind of startup bloat.
It's like opening every tab you'll possibly need for a research session
and then wondering why your laptop sounds like a leaf blower.
The escape hatch is useful precisely because it's narrow.A browser
with 97 tabs is a cry for help,
mate.
But yes - narrow is the point.
Claude Code is basically saying: we still believe in tool-search deferral,
because giant catalogs can bloat the context window.
We are just admitting that, for a few servers,
deferral flips from safety into nuisance.
And that's the part I'd want
listeners to remember: this doesn't kill lazy-loading.
It lets you choose where laziness is smart and where it's just getting
in the way.
That's a very different philosophy from "load everything" or "load nothing."The
same v2.
1.121 release had a second change that I think is actually more
explosive.
PostToolUse got widened socan replace the output of ANY built-in tool,
not just MCP tools.
So now a hook can rewriteoutput,
file reads, other native tool results - before Claude sees them.[questioning
tone] Wait - any built-in tool?
Not just MCP?
So ifspits out a log full of secrets,
a hook can scrub that before Claude ever reads it?
Exactly.
And "scrub secrets from shell output" is one really practical use case.
Another is normalizing noisy logs so the model doesn't get distracted
by garbage.
Another is injecting context into a result - like,
basically shaping the tool output into a cleaner object for Claude to
reason over.
That phrase -- is the bit that'll stick for me,
because it's deceptively tidy.
It sounds like formatting.
But this is more than formatting.
If Claude acts on the rewritten output instead of the raw output,
you've moved the trust boundary.
That's a big old shift.Yes.
That's the exact tension.
The automation upside is real,
but Claude is now responding to the edited version.
So if your hook silently blanks a line,
truncates something important,
or mangles aresult, Claude can continue on a false premise.
Not because the model hallucinated - because YOU fed it a distorted tool
result.
And that's nastier than a normal bug,
hey, because it can look clean.
If a shell command really failed loudly,
you'd notice.
If a hook politely rewrites that output into something half-wrong...
Claude strolls ahead like nothing happened.
That's the software equivalent of painting over the check-engine light.
Painting over the check-engine light is perfect.
And this is why I'd treat hooks like production code,
not glue code.
Test them.
Version them.
Be explicit about what they redact,
what they normalize, what they preserve.
Because onceand file reads are in scope,
the blast radius is way wider than "my MCP integration is quirky."The
phrase "blast radius" is bang on.
Built-in tools are the bones of the session.
If you rewrite those, you're not just accessorizing the workflow - you're
changing the evidence Claude uses to think.
I mean, that's powerful...
and a little spicy.And tucked into that same release were
two less flashy fixes that, honestly,
might save more people actual pain.
One fix addressed unbounded RSS growth that could climb into MULTI-gigabyte
territory during image-heavy sessions.
Another fixed an almost 2 GB leak inon machines with huge transcript
histories.
No config change, just upgrade.
Multi-GB RSS during image-heavy sessions,
and nearly 2 GB leaking in- those are not cute little papercuts.
That's your machine getting bogged down while you're trying to work.
And the nice bit is, unlike the hooks stuff,
there's no philosophical decision tree there.
Just update the thing.
Right.
One part of this release says,
"here's more control." The memory fixes say,
"also, sorry, this should've been tighter." I actually like
that combination.
Give people sharper tools, but also reduce the background instability
that makes power features scary.
Though it does land us in an interesting
spot.
With, you're deciding what tools Claude sees earlier.
With, you're deciding what Claude thinks those tools SAW.
That's...
not the same level of control.
One is convenience.
The other is epistemology with a config file.
That's the cleanest way to put it.
Claude Code is getting more configurable at the tool boundary,
which is great.
But the more you rewrite inputs and outputs,
the more the real question stops being what Claude can see - and becomes
who gets to decide what it thinks it saw.And if your team can't
answer that clearly, maybe don't hand the kangaroo the car keys just yet.
Catch you next time.