Sign up
View stargazersSign up

[Bug]: PR handoffs (Resolve/Fix/Checkout) check out into an unrelated project when the linked repository has no matching checkout#16455

opened28d agobyAAbsterrg0

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Have two GitHub-backed projects in one environment, e.g. unrelated (added first, acme/unrelated) and app (added later, acme/app).
  2. In a thread of app, link a pull request under a repository name that no local project matches. The way I hit it: the agent linked old-org/app#123, then the repository was renamed/transferred to acme/app and the checkout's remote was updated. GitHub still redirects the old name. A thread linked to a PR in a repository you have no checkout of (frontend thread → backend PR) takes the same path.
  3. Make that PR conflict with its base, open the thread details panel, and press Resolve on the PR row (Fix / Checkout from the PR panel behave the same).

Expected behavior

The handoff checks the PR out in the project that is actually a checkout of that repository, or, when there isn't one, refuses with a clear message ("No project here is a checkout of acme/app").

Actual behavior

The checkout and the new thread land in unrelated. The worktree is created under ~/.t3/worktrees/unrelated/t3code-pr-123-..., the PR head (and, for a fork PR, the fork's history) is fetched into unrelated's repository, its setup script runs, and the conflict-resolution prompt is put in a composer of the wrong project. The toast reports success, so nothing suggests it went wrong. The fetch into an unrelated repo also makes the handoff very slow.

Cause:

  1. ThreadDetailsPrRow sends the stored link as the reference: { projectId: app, host: "github.com", repository: "old-org/app", number }.
  2. requireProject (apps/server/src/pullRequest/PullRequestService.ts) finds the own project's repository doesn't match, no project on the host matches either, and falls back to onHost.find((candidate) => candidate.api.kind !== "azure-devops"), which is the first GitHub project in project order. That fallback exists so a thread can read a PR from another repository with any checkout's credentials, and the read succeeds (GitHub follows the rename).
  3. detail then reports that borrowed project as projectId / workspaceRoot, and usePullRequestHandoffs.startHandoff (apps/web/src/components/pullRequest/usePullRequestActions.ts) opens the thread and runs preparePullRequestThread there. GitManager.preparePullRequestThread does not check that the PR belongs to the cwd's repository.

Repro at the service level: with projects [unrelated (acme/unrelated), app (acme/app)], service.detail({ projectId: "app", host: "github.com", repository: "old-org/app", number: 123 }) returns projectId: "unrelated", workspaceRoot: "/unrelated".

Suggested direction: keep the borrowed-credentials route for reads, but don't present the borrowed project as the PR's checkout. Handoffs should refuse (or pick the real checkout) when no project's repository matches. Optionally, refresh a link's stored repository from the canonical URL the host returns, so links survive renames/transfers.

Impact

Major degradation or frequent failure

Version or commit

main @ d60a71ef6

Environment

Linux (Fedora 44), desktop app, Claude provider

Workaround

Re-link the PR under its current repository name, or check the branch out manually in the right project.

JJulius Marminge28d ago

Note

Grok responding on behalf of Julius.

Triage

Thanks @Absterrg0 for the clear write-up. I read this against main (9bd1d8009a, which contains the reported d60a71ef6). The report matches the code, and I didn't find another issue for this handoff landing in the wrong project.

What I found

  • A hosted reference whose repository matches no local checkout is still served. requireProject in apps/server/src/pullRequest/PullRequestService.ts prefers a checkout of that repository, then takes the oldest non-Azure project on the host (projection_projects is ORDER BY created_at ASC, project_id ASC). That donor project is how a read borrows another checkout's credentials, and the test "routes a hosted reference to another repository through a project on that host" covers the read. Azure already requires a matching repository and is left out of this fallback.
  • The donor is then presented as the pull request's project. On that path the route keeps the donor's project id and workspaceRoot and only rewrites repository and remote, and detail and summary copy those into projectId and workspaceRoot. Since the match is a string compare of the stored owner/repo, a link to old-org/app resolves to the oldest project even when another project is the checkout of the renamed acme/app. GitHub follows the rename, so the read itself succeeds.
  • Resolve, Fix, and Checkout follow that identity. The thread-details row (ThreadDetailsPrRow → usePullRequestHandoffs) opens the thread on detail.projectId and runs git.preparePullRequestThread with cwd set to detail.workspaceRoot. PullRequestDetailPanel has its own copy of the same handoff and uses the same values when opened from a thread. The success toast is the checkout toast, so a wrong project still looks successful.
  • GitManager.preparePullRequestThread doesn't check that the cwd is a checkout of the pull request's repository. Worktree mode fetches the head through materializePullRequestHeadBranch (ensureRemote plus a fetch into that cwd), which is why the worktree shows up under the unrelated project. For comparison, a hostless reference naming another repository already fails with "The change request does not belong to the selected project."

Likely fix area

Some options, which could keep reads working through another checkout's credentials while not using that donor as the checkout target:

  • Have detail and summary identify only a real checkout of the repository, or leave the checkout target empty when there isn't one.
  • Have both handoff paths refuse with a clear message when no project is a checkout of that repository.
  • Add a guard in preparePullRequestThread that refuses a cwd whose remote is a different repository.
  • Separately, rewrite a stored link to the canonical owner/repo the host returns, so a renamed or transferred repository matches the checkout that already has the new remote.

Until then, re-linking under the current repository name, or checking the branch out in the right project manually, avoids it.

A maintainer will decide on the fix direction.

JJulius Marminge12d ago

Reproduced on current main ed9b7ca9c5, Linux web client against an isolated dev server. With two disposable GitHub-backed projects and no checkout of the linked PR repository, pullRequests.detail returned the first unrelated project. Both Check out → In a separate worktree and Fix opened a draft in that project and started fetching the PR fork there. The checkout attempts ended with a branch-materialization error here; the wrong destination and added fork remote were observable before that.

Runtime transcript · Fix action recording

Wrong-project draft during checkout preparation