Welcome to the show - James,
I wanna start with three URLs that tell the whole story: `https://gitlab.
com/org/repo/-/merge_requests/99`,
`https://bitbucket.
org/org/repo/pull-requests/7`,
and `https://github.
internal.
co/org/repo/pull/42`.
Yeah, and that last one - `github.
internal.
co` - is the giveaway.
That is not hobby-project land.
That's corporate VPN, internal certs,
weird SSO, somebody's security team breathing down your neck.
Exactly.
And in Claude Code v2.
1.119, `claude --from-pr` now accepts all of those
patterns, not just plain old `github.
com`.
So GitLab merge requests, Bitbucket pull requests,
and GitHub Enterprise PRs all work.
Which sounds tiny...
but mate, it's not tiny at all.The version number
there - v2.
1.119 - is one of those deceptively boring releases.
No fireworks, but if your team lives on GitLab,
the difference is basically zero workflow versus actual workflow.
That's
the bit.
People hear, "oh, they added more URL support." Nice-to-have.
Little checkbox feature.
But for loads of real engineering teams,
especially enterprise mobs on internal GitHub Enterprise or shops that
standardized on GitLab, `GitHub-only` wasn't a limitation - it was a HARD
blocker.
You couldn't really use the command the intended way,
full stop.Let me push on that,
though.
Because if you're determined enough,
you can always copy and paste a diff,
paste the PR description, maybe dump the commit list.
Annoying, sure.
But blocker?Yeah, blocker.
Because the whole magic of `--from-pr` is that the session starts with
the full diff, the commit list,
and the PR description ALREADY loaded.
Not eventually, not after ten minutes of manual setup.
Immediately.
That means Claude can start doing useful work right out of the gate -
review the change, suggest tests,
help debug why CI is falling over.
If you have to hand-feed all that context every time,
the workflow becomes like kick-starting an old trail bike with thongs
on - technically possible, deeply stupid.The "full diff,
commit list, and PR description"
trio is the key.
Because those are three different layers of intent.
The diff is what changed.
The commit list is how it evolved.
The PR description is what the author thinks they're doing.
If you miss one, you can misread the whole thing.
Beautifully put.
And that's why this release feels practical rather than flashy.
It matches how review actually works in the trenches.
You don't review code in a vacuum.
You review a change set, with history and explanation attached.
So do you see this as Claude Code becoming more of a review companion
than a coding assistant?
Because `--from-pr` is not "help me write a function." It's more like,
"jump into an active engineering conversation."I think that's fair...
though not exactly either-or.
It's still a coding assistant.
But this feature leans hard into the review side of engineering,
which honestly is where a lot of time gets chewed up.
Writing code is one part.
Understanding someone else's code at 4:47 p.
m.
before stand-down?
That's the real wrestle.
And the CI angle matters.
You mentioned debugging failures.
If the PR context is preloaded,
you're not starting from, "hey Claude, here's a vague problem." You're
starting from PR 99 on GitLab or PR 42 on GitHub Enterprise with the exact
proposed change in front of you.
That's a much better prompt surface.
Right.
It reduces that dreadful context tax.
Developers pay this little tax all day - copy this,
explain that, paste logs, paste the summary,
whoops forgot the commit that introduced the regression.
This shaves that off.
And shaving off setup friction matters more than people admit,
because tiny bits of friction are where tools quietly die.
I think that's the surprise here.
The headline looks like "more providers supported." The real story is:
the tool now fits the existing review ritual of more teams.
And engineers are creatures of ritual.
If a tool asks them to leave the PR,
reconstruct context, and babysit it,
they won't do it consistently.
Yep.
Finally the tool matches how real teams actually work,
rather than how a neat demo works on a sunny day with a public GitHub
repo.
And, look, that's maturity.
Less "look what we can do," more "here's how your workplace actually
behaves."[short
pause] The `https://bitbucket.
org/org/repo/pull-requests/7` example sticks
with me, weirdly.
Because Bitbucket users are always the ones left out in these launches.
It's like every tool says "supports code hosting," and then whispers,
"well...
one code host."Bitbucket users finally getting invited
to the barbie.
Love that for them.
The other half of v2.
1.119 is quieter,
but maybe even more revealing.
Claude Code output used to handle `owner/repo#N` shorthand as if the
world was always `github.
com`.
Now that shorthand points to YOUR git remote host instead.[questioning
tone] And "your git remote host" is the important token there.
So if your repo lives on `gitlab.
com`,
or `github.
mycompany.
com`, or some other host,
the link doesn't just punt you off to the wrong neighborhood anymore.
Exactly.
It sounds cosmetic - just a link,
who cares.
But bad links are one of those paper-cut bugs that make software feel
fake-enterprise.
The output says `owner/repo#N`,
you click it, and suddenly you're on public GitHub looking at nothing
useful.
That breaks trust fast. Yeah,
because a shorthand only saves time if it lands in the right paddock.
Otherwise it's not shorthand, it's a detour.
And for teams on internal hosts,
that detour can be impossible,
not just annoying.
Then there's the `prUrlTemplate` setting,
which is a really nerdy little power feature.
Teams can customize where that footer PR badge links.
So if you're not using a standard GitHub-style pattern,
you can point it somewhere else entirely.And the named examples
there - Gerrit and Phabricator - are doing a lot of work.
Because those platforms tell you this isn't just "GitHub plus maybe GitLab."
It's acknowledging that some engineering orgs have genuinely weird,
legacy, or deeply internal review systems.
Right.
Gerrit, Phabricator, internal review tools - those aren't edge cases
in big companies.
They're just reality.
So `prUrlTemplate` says, "fine, tell us your pattern." That's a very
different philosophy from forcing everybody into one URL shape.
I was gonna
say it's glamorous, but it's the opposite.
It's infrastructure thinking.
Portable, configurable, less opinionated.
Same with the `CLAUDE_CODE_HIDE_CWD` tweak.
That hides the working directory from the startup logo,
which is a tiny blessing if you're screen-sharing or doing a live demo.
The
variable name itself - `CLAUDE_CODE_HIDE_CWD` - is hilariously
blunt.
But on a call, your current working directory can absolutely leak stuff.
Project names, customer names,
internal folder structures, maybe even your username.
I've seen worse exposed in demos. Oh,
same.
Nothing wakes you up faster than realizing you've just shown
`/clients/very-sensitive-thing/do-not-shar e`
to twenty people on Zoom.
Hiding the CWD is not some grand innovation.
It's just respectful software.
It understands that developers work in public sometimes.
And when you
line these up - `--from-pr` for GitLab,
Bitbucket, GitHub Enterprise; shorthand links resolving to the actual
remote host; `prUrlTemplate`; `CLAUDE_CODE_HIDE_CWD` - the pattern is
obvious.
This release is about portability across engineering stacks.
Yeah.
Less opinionated about where your code lives,
where your reviews happen, what weird system your company inherited in
2014 and never escaped.
That's healthy.
Good dev tools shouldn't make you rearrange the org chart just to use
them.
I think that's the bigger shift.
Not "Claude Code learned a new trick." More like: Claude Code is admitting
the software world is messy, multi-host,
full of enterprise oddities, and not everybody lives on clean public
GitHub.
And honestly, that's when tools become real.
Not when they ace the demo, but when they survive the weirdness.
The internal host.
The custom review path.
The screen share you forgot was exposing too much.
That's the stuff that separates a clever toy from something a team can
actually adopt.Which leaves a nice question hanging: if the model
is getting less opinionated about the stack around it,
does that make the assistant more useful - or just more invisible?
Because the best tooling in engineering often disappears into the workflow.
If it disappears into the workflow,
mate, that's usually a very good sign.
Catch you next time.