Jellypod, Inc.

The Claude Code Changelog

TechnologyNews

Listen

All Episodes

Claude Code Goes Beyond GitHub

This episode breaks down Claude Code v2.1.119’s expanded support for GitLab, Bitbucket, and GitHub Enterprise PRs, plus the value of loading full diff, commit, and description context automatically. It also covers smarter PR link handling, configurable review URL templates, and a small privacy win for demos with hidden working directories.

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.

Get Started

Is this your podcast and want to remove this banner? Click here.


Chapter 1

Finally not just GitHub

Lachlan Reed

Welcome to the show — [excited] 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`.

James Turner

[questioning tone] 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.

Lachlan Reed

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.

James Turner

[responds quickly] 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.

Lachlan Reed

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.

James Turner

[skeptical] 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?

Lachlan Reed

[calm] 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.

James Turner

[laughs] 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.

Lachlan Reed

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.

James Turner

[curious] 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."

Lachlan Reed

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.

James Turner

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.

Lachlan Reed

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.

James Turner

[reflective] 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.

Lachlan Reed

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."

James Turner

[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."

Lachlan Reed

[chuckles] Bitbucket users finally getting invited to the barbie. Love that for them.

Chapter 2

Small link fixes, bigger portability

James Turner

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.

Lachlan Reed

[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.

James Turner

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.

Lachlan Reed

[matter-of-fact] 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.

James Turner

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.

Lachlan Reed

[curious] 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.

James Turner

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.

Lachlan Reed

I was gonna say it's glamorous, but it's the opposite. [laughs] 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.

James Turner

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.

Lachlan Reed

[warmly] Oh, same. Nothing wakes you up faster than realizing you've just shown `/clients/very-sensitive-thing/do-not-share` 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.

James Turner

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.

Lachlan Reed

[reflective] 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.

James Turner

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.

Lachlan Reed

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.

James Turner

[softly] 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.

Lachlan Reed

[calm] If it disappears into the workflow, mate, that's usually a very good sign. Catch you next time.