Does this change alter worktree's own behavior, or only the way input is given?
Only the input method changed — once a worktree is created, its behavior is exactly the same as before. Whether you paste a plain number with #, a GitHub pull request URL, or a GitLab merge request URL, Claude Code parses out the same core piece of information in the end — which numbered change request this is — and then follows the same logic to fetch the corresponding head commit from your repository's origin remote, creating it under the same directory-naming convention (.claude/worktrees/pr-<number>).
In other words, this update solves the input-layer problem of "what format do you use to tell Claude Code which change you want," not the core logic of how worktrees are created, isolated, and managed — that whole mechanism is unchanged before and after this update.
Why does a small change like "support more input formats" deserve a dedicated write-up?
Looking at this one feature in isolation, it really is just saving one manual conversion step, with a fairly narrow impact. But it reflects a broader pattern: many of Claude Code's features were originally designed with GitHub as the default target, and GitLab support tends to arrive later as a follow-up — that ordering often means GitLab users have to take an extra detour on certain details compared to GitHub users, even when a feature technically exists for both.
This update to --worktree closes that specific gap — GitLab users can now use this feature in exactly the same way as GitHub users (paste the URL directly), without doing any format conversion in their head. For a team with people on both platforms, this kind of "input parity" arguably matters more than the value of the single feature itself, because what it reduces is the internal communication cost that arises from different tooling habits within the same team.
Once you paste the URL, how does Claude Code actually fetch the corresponding change? Do I need to configure anything for this?
No extra configuration is needed — the whole fetching process is automatic. Claude Code only reads the number out of the URL; when actually fetching the change's content, it always goes through your repository's already-configured origin remote, rather than connecting to whatever domain appears in the URL you pasted. That means even if the URL you copied doesn't exactly match your repository's actual remote configuration, as long as the number is correct, the fetch still succeeds — because the system trusts the origin configuration, not the domain in the URL itself.
The fetch path is determined automatically based on the host type origin points to: for GitHub Enterprise, a self-hosted GitLab instance, or any other host type, the system tries the path pull/<number>/head first, and falls back to merge-requests/<number>/head if that fails. This "try one, fall back to the other" mechanism was added specifically in this update — before 2.1.233, the system always tried only the single path pull/<number>/head.
If my team uses both GitHub and GitLab, how should we actually adjust team workflow habits to take advantage of this update?
The most direct adjustment is no longer needing to maintain two separate sets of instructions for "how to tell Claude Code which change to work on" across the two platforms. Previously, you might have had to specifically tell GitLab users to "first find the number on the MR page, then use # plus that number" as an extra step. Now it can be unified into one sentence: "paste the MR or PR URL directly into --worktree" — no need to distinguish which platform the other person is on.
A more granular detail: if your team runs a self-hosted GitLab or GitHub Enterprise instance, the system tries pull/<number>/head first and falls back to merge-requests/<number>/head only if that fails. If your self-hosted environment has unusual path-naming logic — say, it sits behind a reverse proxy or has a customized API path — and you run into a fetch failure, it's worth first confirming whether neither of these two standard paths matches your environment, rather than immediately assuming --worktree itself is broken.
Claude Code version 2.1.233 (part of the August 2026 update sequence) added a small but genuinely useful change to --worktree: you can now paste a GitLab merge request URL directly, with no need to look up the corresponding number yourself or manually convert the format first. This piece covers exactly how this works and how it differs from the old behavior.
--worktree lets you create an independent checkout for a specific branch without touching your main working directory. A common scenario: you're in the middle of working on a feature branch, and you suddenly need to look at a PR or MR without wanting to interrupt what you're doing, and without wanting to stash your current uncommitted changes. With a worktree, you can open a separate directory and have Claude Code handle that other thing there, with neither side interfering with the other.
Before this update, --worktree only accepted two kinds of input: a number prefixed with # (like #123), or a GitHub-style pull request URL. If your project used GitLab and you wanted to handle a merge request through a worktree, you had to first go find the corresponding number on the MR page yourself, then manually assemble the #-plus-number format to paste into Claude Code — one extra conversion step, and if a team had some people on GitHub and others on GitLab, this asymmetry in input format could easily cause confusion.
Now you can paste a full URL like https://gitlab.com/group/repo/-/merge_requests/123 directly into --worktree, and Claude Code parses the number out of the URL on its own — no conversion needed beforehand. When actually fetching the change's content, Claude Code always fetches that change's head commit from your repository's origin remote, choosing the fetch path based on the host type origin points to. For GitHub or a self-hosted GitLab instance, it tries pull/<number>/head first, then falls back to merge-requests/<number>/head if that fails. The resulting worktree is always stored at .claude/worktrees/pr-<number> — whether you paste a GitHub URL, a GitLab URL, or just a plain number, the resulting directory-naming logic is consistent.
Because the # character gets treated as the start of a comment in most shell environments, if you're using the plain-number-plus-# format directly (like #123), remember to wrap the entire argument in quotes — otherwise the shell may silently drop everything after the #. Also, since a worktree is essentially a fresh checkout, untracked files in your main working directory — local config files like .env or .env.local — won't automatically appear in the newly created worktree. If your task needs them, you'll need to copy them over manually.