Repository navigation
[Bug]: Pull request pane treats SSH aliases as GitHub API hosts #6198
Description
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
-
Configure a GitHub SSH alias:
Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal
-
Use that alias in a repository remote:
git@github-personal:OWNER/REPOSITORY.git -
Open the repository in T3 Code on a branch with an open pull request.
-
Click the pull-request indicator from the thread view.
-
Observe the new in-app pull-request pane.
Expected behavior
The pane should use github.com as the GitHub API/browser host while preserving github-personal for Git SSH authentication.
Actual behavior
T3 derives the repository's canonical host directly from the remote and records github-personal as a self-hosted GitHub hostname. The pull-request pane then invokes GitHub CLI against github-personal, so it cannot load the pull request.
The previous behavior opened the pull-request URL externally, so this became visible after the in-app pane was introduced in #4849.
Impact
Major degradation or frequent failure
The pull-request pane is unavailable for every repository using the common SSH-alias pattern for multiple GitHub accounts.
Version or commit
main @ 3517201
Environment
Linux 7.0.0-29-generic x86_64
gh 2.97.0
OpenSSH 10.2p1
Affects the web UI and desktop wrapper
Logs or stack traces
$ ssh -G github-personal 2>/dev/null | awk '$1 == "hostname" { print $2; exit }'
github.com
$ gh repo view github-personal/pingdotgg/t3code --json nameWithOwner --jq '.nameWithOwner'
error connecting to github-personal
$ gh repo view github.com/pingdotgg/t3code --json nameWithOwner --jq '.nameWithOwner'
pingdotgg/t3codeWorkaround
Open the pull request manually in the browser. Changing the remote to use github.com also avoids the problem, but can disrupt multi-account SSH key selection.
Implementation
I’d be happy to prepare a focused PR after maintainers confirm the preferred normalization boundary.
Activity
maslinedwin commentedon Aug 16, 2026
Fix is in #7186. SSH aliases like
github-personalare resolved to their HostName before the pull-request pane talks to GitHub.t3dotgg commentedon Sep 4, 2026
Note
🤖 GPT-6 Astra (preview) responding on behalf of Theo
This note is part of an automated cleanup pass.
Related report #9458 adds a dotted SSH alias on macOS 15.7.4 with T3 Code v0.0.38. Its config uses Host github.com-customalias, HostName github.com and an account-specific IdentityFile. The remote is [email protected]:organization/repository.git, which produces an invalid HTTPS host. Preserve this case when resolving SSH HostName, and leave the raw Git remote unchanged so push and pull keep the selected key. #7186 currently resolves only undotted aliases, so that candidate does not yet cover this reproduction.
Mnigos commentedon Sep 7, 2026
The dotted-alias case from #9458 (
Host github.com-customalias→HostName github.com) is what #7186 still misses: its gate skips any alias that contains a dot. I had that handled in #9497 before it was closed as a duplicate, so I can carry it over as a small change on top of the current host resolution, keeping the raw remote untouched so push and pull keep the selected key. Happy to do that unless #7186 is about to pick it up.juliusmarminge commentedon Oct 6, 2026
Note
Grok responding on behalf of Julius.
Fixed by #16321, which landed on main today. A dotless SSH host such as
github-personalis now treated as an alias forgithub.com, so the pull request pane reads the PR through the github.com API while git keeps using your alias. Closing; reopen if it still happens on the next nightly. (#14919 stays open for keying aliased remotes by their realHostNamein the sidebar.)