PR checkout fails due to branch name collision after #851

[kirisame-wang]

Describe the bug

PR #851 introduced a bug where PR checkout fails if the PR branch name conflicts with existing branches in the base repository.

The new checkout strategy git fetch origin pull/${number}/head:${branchName} attempts to create a local branch with the PR's branch name, which fails when that branch name already exists locally or remotely in the base repo.

To Reproduce

Steps to reproduce the behavior:

1. Create a branch named feature/my-feature in your base repository
2. Create a PR (from same repo or fork) using the same branch name feature/my-feature
3. Trigger the claude-code-action workflow on that PR
4. See error:

git fetch origin --depth=20 pull/123/head:feature/my-feature
fatal: refusing to update ref with bad name 'feature/my-feature'

Expected behavior

The workflow should successfully checkout the PR regardless of branch name conflicts. The PR should be fetched and checked out to a local branch without naming collisions.

Screenshots

N/A

Workflow yml file

N/A

API Provider

[x] Anthropic First-Party API (default)
[ ] AWS Bedrock
[ ] GCP Vertex

Additional context

Background:
PR #851 was introduced to support fork PRs, which is a valuable improvement for organizations like PyTorch where 90%+ PRs come from forks.

Before #851:

• Used git fetch origin <branch-name> - only works for same-repo PRs
• Fork PR branches don't exist in the base repo's origin, causing fetch failures

After #851:

• Uses GitHub's refs/pull/NUMBER/head which exists for all PRs (both same-repo and fork)
• Successfully enables fork PR support

Root cause:
The new implementation uses git fetch origin pull/${number}/head:${branchName}, where :${branchName} creates a local branch with the PR's original branch name. This avoids detached HEAD state but introduces naming collisions when:

• A local branch with the same name already exists
• The workflow is currently checked out to that branch
• The base repo has a remote branch with the same name

The issue is a trade-off: while #851 solved the fork PR problem, it created a new branch naming conflict problem.

[surejainam]

Facing the same issue !!

[AlexanderBartash]

The same issue, action does not work anymore.

[awittzb]

#851 also broke my uses of the claude-code-action - just for regular PRs, not even involving forks.

I was already checking out the code & setting up the git refs exactly how I wanted it to be seen by Claude Code. The claude-code-action should not check out or overwrite the state that the worfklow that calls it has set up.

Actions should not checkout code or "set up" the git repository - the calling Workflows should.

This is crucial, since you may string multiple Actions together in a Workflow and if they're each manipulating the repository, it becomes incredibly difficult to get correct results.

---

If a checkout change to how the Action manipulates the git repository is going to be introduced to claude-code-action regardless of that, we can see that doing so is a breaking change and should be released as a new major version.

If a checkout change to how the Action manipulates the git repository is desirable in order to solve a certain class of problems (e.g. #851), then, the change should be optional and off-by-default to avoid breaking existing consumers.

[kirisame-wang]

I think this is possibly a design concern regarding whether claude-code-action should be self-contained enough to prepare the environment for its work, or if it should follow the Single Responsibility Principle at some level.

There are pros and cons to both approaches. However, when users need to prepare environments for their specific purposes, changes introduced by PR #851 can indeed cause conflicts with checkout actions executed in earlier steps of the workflow, prior to claude-code-action.

To address this, making the relevant functionality optional and off by default seems like a viable path. One possible fix that focused on PRs coming from forked repositories is demonstrated here by @izaitsevfb. Alternatively, a simpler approach is to resolve the naming conflicts by using a unique branch name, as in PR #931.

[surejainam]

When can we expect a resolution on this? The action is completely unusable

[kirisame-wang]

When can we expect a resolution on this? The action is completely unusable

We could temporarily pin the action version to v1.0.47.

[ashwin-ant]

Just released #931 in 1.0.48! Thanks for reporting.