/ Claude Code v2.1.136

Fixed --worktree starting before workspace trust is accepted, replacing a later failure with a direct trust message. Evidence: trust gate added before worktree creation (search for "Workspace trust not yet accepted")

Improved PowerShell 5.1 command safety detection for cwd-first command shadowing. Evidence: new warning for commands that create a file which shadows a later command (search for "Windows PowerShell 5.1 cwd-first resolution")

Improved PowerShell validation around runtime-resolved Unicode codepoint escapes. Evidence: new classifier message (search for "PowerShell \u{HEX} codepoint escape is runtime-resolved and cannot be statically validated."`)

Fixed bare Git repository detection to recognize .git files that contain gitdir: and avoid misclassifying linked worktrees or nested repositories. Evidence: updated Git structure detection (search for "gitdir:")

How sure we are

One source agreesOne thing we can check says the same as this entry.

Anthropic's release notes agreeImproved error message when --worktree collides with an existing or stale worktree

See this entry in the whole of v2.1.136 →

The build it came inv2.1.136

8 May 2026 · 9 entries, this one is #9.

Either side of it

v2.1.133Older
v2.1.137Newer

Open the release →

Names in this entry

cli--worktree
Start Claude in an isolated git worktree at <repo>/.claude/worktrees/<name>. If you don't give a name, Claude Code generates one. Pass #<number>, a GitHub pull request URL, or a GitLab merge request URL to fetch that PR or MR from origin and branch the worktree from it. Branching from a GitLab merge request requires Claude Code v2.1.233 or later

Anthropic's note

Upstream's own release notes for v2.1.136 name something this entry names, so the two are probably about the same change. Probably: the pairing is made on a shared name rather than on the words around it.

Improved error message when --worktree collides with an existing or stale worktree

Is this right?