[Bug]: Remotes on ssh.bitbucket.org (forge SSH hosts) don't match their PRs' repository#22620

opened14d agobyIitizarsa

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

owner/repo is a placeholder.

Clone a Bitbucket repo through Bitbucket's own SSH host: git@ssh.bitbucket.org:owner/repo.git (Bitbucket documents this host; it's also what HostName points to in many ~/.ssh/config setups).
Register the checkout as a project. Its repositoryIdentity.canonicalKey becomes ssh.bitbucket.org/owner/repo (provider correctly detected as bitbucket).
Ask T3 to write a review guide for a PR in bitbucket.org/owner/repo.

Expected behavior

The project is matched to the PR's repository and the guide is written.

Actual behavior

Guides are written from this project's checkout, and this pull request is in another repository. Write it from a project that is a checkout of that repository.

The canonical key keeps the SSH host (ssh.bitbucket.org), while the PR's repository is keyed by bitbucket.org, so the comparison fails. Changing the remote to git@bitbucket.org:owner/repo.git works around it.

The same likely applies to ssh.github.com (GitHub's SSH-over-443 host) and any other forge SSH hostname that differs from its web host.

Impact

Minor bug or occasional failure

Version or commit

T3 Code (Alpha) 0.1.1

Environment

macOS 26 (Darwin 25.6.0), desktop app

Workaround

Point the remote at the web host: git remote set-url origin git@bitbucket.org:owner/repo.git (SSH still works if ~/.ssh/config maps bitbucket.org to HostName ssh.bitbucket.org), then reload the project.

Suggested fix

Normalize known forge SSH hosts to their web host when building the canonical repository key (ssh.bitbucket.org → bitbucket.org, ssh.github.com → github.com), or compare by provider + owner + name instead of the raw host.

Related: #17805 (SSH host aliases classified as provider unknown) — different symptom, same root area (remote host → repository identity).

This issue was diagnosed and written by Claude Opus 5.5 (Claude Code, running in T3 Code).

JJulius Marminge14d ago

Note

Grok responding on behalf of Julius.

Thanks for the clear report. Current main matches it. The repository key is built from the remote's host and path as written (packages/shared/src/git.ts:144-174). The only forge whose SSH host gets mapped to the same key as its web host is Azure DevOps (lines 129-142). So git@ssh.bitbucket.org:owner/repo keys as ssh.bitbucket.org/owner/repo, while the pull request's repository keys as bitbucket.org/owner/repo, and the two never match. The same would apply to ssh.github.com, GitHub's SSH host on port 443.

Switching the remote to git@bitbucket.org works, but ssh.bitbucket.org is a host Bitbucket documents itself, so it shouldn't need a workaround. This is separate from #17805, which is about custom SSH aliases from your own SSH config. These are fixed hosts the forges publish, so they can be recognized directly.

Accepting this as a bug.

JJSReek6d ago

@juliusmarminge is there something that's still required to get this moving?

Wwongcallum2d ago

fwiw I get this on ssh.github.com, and the Create PR button in thread details fails because of it. The error hint was misleading too:

1	Source control provider github failed in listChangeRequests: No GitHub credential for ssh.github.com: run `gh auth login --hostname ssh.github.com`.