Welcome to the show.
James, May 4th, 2026 -- Claude Code v2.1.128
ships, and buried in the notes is one of those little Git lines that can absolutely
make your stomach drop.
`EnterWorktree` used to branch from `origin/`.
Now it branches from your local `HEAD`.
Which means before this fix, if you had unpushed commits sitting locally,
the new worktree could quietly ignore them.
Wait -- `origin/` versus local `HEAD` is not a tiny distinction.
That's the difference between "branch from what I ACTUALLY have on my machine" and
"branch from whatever I last shoved up to remote."
If I've got a WIP commit locally, that agent is basically starting from yesterday's
news.
Exactly.
And that's the sneaky bit.
The worktree looked normal.
Nothing was obviously on fire.
No big red warning, no busted checkout.
But unless you were the sort of maniac -- and I say that lovingly as a web dev who's
done this in a panic at midnight -- unless you checked `git log` in both places,
you'd have no clue your fresh agent branch was based on stale remote state.
And that is the WORST category of bug.
Not a crash.
Not a loud failure.
A liar.
Because if the branch opens fine, files are there, everything feels clean...
you trust it.
Then twenty minutes later you're asking, "Why doesn't the code match?"
and the answer is: because the base was wrong before you even started.
Yep.
Multi-agent workflows lean on worktrees for isolation.
That's the whole bargain, right?
One agent here, another over there, everyone's got their own little fenced paddock.
But if those paddocks start from different realities -- one from local truth,
one from stale remote truth -- you're not isolating work, you're splitting reality.
Proper dog's breakfast.
"Splitting reality" is good.
[short pause] Because in practice it's not just one missing commit.
It's interpretation drift.
Agent A sees the local fix you made.
Agent B, launched through the buggy path, doesn't.
Now they generate different edits, different assumptions, maybe even different bug
reports.
And none of that LOOKS like a Git-base problem at first.
Right, and from the dev side, that's the gut-punch.
You trust a tool to just do the sensible thing.
Especially with worktrees, because they're meant to be the tidy option.
Then later you realize it respected the docs less than your actual repo state.
[laughs softly] Mate, that's like asking someone to copy your shopping list and they
faithfully copy last week's receipt instead.
Last week's receipt is perfect.
And I think the horror lands hardest on that phrase "silently skipped."
If an unpushed local fix gets silently skipped, it means the important information
wasn't missing from Git.
It was present.
It was right there in your local `HEAD`.
The wrapper just didn't use it.
And to be fair, now it does.
In v2.1.128, `EnterWorktree` branches from local `HEAD`, so unpushed commits
are finally included instead of being left behind.
But I do think this is one of those bugs that's worth talking about because loads of
developers would've had that weird, low-grade feeling of "hang on...
why is this branch off?"
without ever catching the exact cause.
Let me try to say it back.
Before May 4th, 2026, if I spawned a worktree through `EnterWorktree`,
I might THINK I was branching from my current working reality,
but I was actually branching from `origin/`.
So if I hadn't pushed, the agent missed my latest local commits.
After v2.1.128, it finally branches from local `HEAD`, which is what most developers
would've assumed in the first place.
That's it.
Not a new superpower -- more like the floorboards have been screwed down properly.
And if you've ever nearly tanked a site with one bad assumption -- I have,
long story, awful midnight deploy -- you get very twitchy around tools that fail
quietly.
Quiet bugs are the ones that make you doubt your own memory.
So the key framing here is: this is less a feature change than a correctness repair.
The documented behavior is restored.
If you WANT remote-state branching now, you need to push first or pick a different
base explicitly.
That's a very different mental model from "the tool will secretly choose remote for
me."
[questioning tone] And that's an important distinction, hey,
because plain `git worktree add` still behaves like standard Git.
So the bug wasn't Git being weird.
It was Claude Code's internal `EnterWorktree` wrapper doing something specific in
the agent workflow.
Exactly -- `git worktree add` is standard Git territory.
`EnterWorktree` is the convenience layer.
And when convenience layers drift from expected behavior, that's where trust gets
expensive.
Because developers blame themselves first.
They think, "Did I forget a stash?
Did I checkout wrong?
Did I imagine that commit?"
"Have I become a drongo, or is the tool haunted?"
Those are the two options at 11:47 p.m.
Usually both.
But this release has a broader pattern, and I like that.
The reliability story isn't only the worktree fix.
There's also subprocess OTEL isolation.
Bash, hooks, MCP servers, LSP processes -- they stop inheriting `OTEL_*` variables
and accidentally shipping traces to Claude Code's collector.
`OTEL_*`
is the
memorable
token there for me.
Because environment-variable leakage is another silent one,
right?
Not dramatic.
Just the wrong subprocess inheriting tracing config it shouldn't have,
and suddenly telemetry goes somewhere you never intended.
Yeah, and that phrase "accidentally shipping traces" matters.
We're not talking about some flashy UI bug.
We're talking about background processes -- Bash, hooks, MCP servers,
LSPs -- inheriting state they didn't ask for.
Isolation is the whole game in toolchains like this.
Same theme as worktrees, honestly: keep boundaries real.
That's a nice connection.
Worktree isolation for code state.
OTEL isolation for process state.
In both cases, the fix is basically: stop the invisible bleed-over.
And then there's the other one I think agent users will FEEL immediately: the
parallel tool-call fix.
Before, a failing read-only Bash command like `grep`, `git diff`,
or `ls` could cancel sibling calls.
Now it doesn't.
That is huge for multi-step agent work.
The examples there are so grounded too -- `grep`, `git diff`,
`ls`.
That's not some exotic edge case.
That's bread-and-butter terminal stuff.
If one read-only command hits a dead end and takes down its siblings,
the workflow feels brittle as.
Like one wheel hits a pothole and the whole bike decides the ride is over.
Right.
And in agent workflows, parallel calls are often about exploration.
One command checks files, another diffs changes, another searches text.
If `grep` fails because the pattern isn't there, that should be information,
not a global emergency.
The old behavior basically treated "no result" or "that path's wrong" as a reason to
collapse the whole branch of thought.
Which is very unlike how a good dev actually works.
Humans poke around.
One command fizzles, we try the next thing.
We don't throw the laptop into the bin because `ls` had a sad day.
And that's why these fixes belong together in one conversation.
Worktree bases, OTEL inheritance, sibling-call cancellation -- on paper they're
separate.
But the shared theme is reducing silent interference.
Less hidden state.
Fewer invisible cancellations.
Fewer moments where the tool quietly nudges reality sideways.
Yeah.
The dream with agent tools isn't magic.
It's trust.
If I branch from here, branch from HERE.
If a subprocess shouldn't inherit `OTEL_*`, don't leak it.
If `git diff` fails in one lane,
don't
nuke the other
lane.
Basic stuff...
but basic stuff is what keeps your head straight.
And honestly, that's the takeaway I'd leave people with: not "learn this one weird
bug," but notice which tools fail loudly and which ones fail politely.
The polite failures are the ones that rewrite your assumptions.
Those are the dangerous ones.
Too right.
Push if you want remote truth.
Choose a base if you need one.
But if a wrapper promises isolation, make sure it's not doing a sneaky little side
quest behind your back.
Cheers, James.
See you next time.