Skip to content

[BUG] EnterWorktree/ExitWorktree pins session cwd globally and makes EnterWorktree bind to the wrong repository #59702

Closed as duplicate

Description

@sdi2200262

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet (related but distinct ones are listed at the bottom)
  • This is a single bug report
  • I am using the latest version of Claude Code

What's Wrong?

Using the worktree tools leaves the session working directory permanently pinned. After EnterWorktree then ExitWorktree (either keep or remove), every Bash command appends Shell cwd was reset to <ExitWorktree restore dir> and cd never persists, including when the user types cd via the ! prefix.

Worse, the EnterWorktree tool resolves the "current repository" from that pinned cwd, so once the session is pinned it operates on the wrong repository: a subsequent EnterWorktree created a worktree and branch in an unrelated sibling repository, and EnterWorktree(path=<a correct, registered worktree>) was rejected as "not a registered worktree of ".

No in-session recovery exists. /add-dir <abs> widens the permitted directory set but does not re-anchor the project directory or what ExitWorktree restores to. Only fully restarting Claude Code clears the pin.

What Should Happen?

ExitWorktree should restore the cwd to the session's original launch directory and leave it mutable (the Bash tool docs state cwd persistence is the default). EnterWorktree should resolve its target repository from the session's actual repository context rather than a stale pinned cwd, so it never creates worktrees in an unrelated repository, and EnterWorktree(path=...) should accept a registered worktree of the repository the session is logically working in.

Error Messages/Logs

Shell cwd was reset to /Users/<user>/<repoA>
Cannot enter worktree: /Users/<user>/<repoA>/.claude/worktrees/<name> is not a registered worktree of /Users/<user>/<repoB>.

Steps to Reproduce

  1. Launch Claude Code in repo A (a git repository).
  2. In a Bash call, cd into a sibling git repository B (for example to read a file there), so the persisted Bash cwd is now B.
  3. Call EnterWorktree. It creates the worktree off B (the cwd-derived repo), not A.
  4. Call ExitWorktree (remove or keep).
  5. Every subsequent Bash command prints Shell cwd was reset to <B>; cd to any path, by the agent or by the user via the ! prefix, does not persist.
  6. Call EnterWorktree(path=<a real, registered worktree of A>). It is rejected as not a worktree of B.
  7. Only a full Claude Code restart restores a mutable cwd.

Claude Model

Opus

Is this a regression?

I don't know (the worktree tools are recent; there is no known prior-working baseline)

Claude Code Version

2.1.143 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

zsh

Related but distinct issues

This issue is specifically the EnterWorktree/ExitWorktree restore-anchor pin plus the resulting wrong-repository binding of EnterWorktree, with a full restart as the only recovery.

Activity

  1. github-actions commented on May 16, 2026

    @github-actions

    Found 1 possible duplicate issue:

    1. Can no longer tell Claude to change its working directory mid-session (regression) #42844

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. added
    duplicateThis issue or pull request already exists
    and removed
    bugSomething isn't working
    has reproHas detailed reproduction steps
    platform:macosIssue specifically occurs on macOS
    on May 20, 2026
  3. github-actions commented on May 20, 2026

    @github-actions

    This issue has been automatically closed as a duplicate of #42844.

    If this is incorrect, please re-open this issue or create a new one.

    🤖 Generated with Claude Code

  4. github-actions commented on Jul 9, 2026

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  5. locked as resolved and limited conversation to collaborators on Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions