Skip to content

gh stack submit fails when remote uses a custom SSH host alias #45

Closed
#554
Closed
gh stack submit fails when remote uses a custom SSH host alias#45
#554
Labels
bugBug Reportstopic: cli - submit`gh stack submit`: remote/SSH handling, config flags, draft PRs, and submit UX or failures.

Description

@EricCrosson
EricCrosson
opened on Apr 16, 2026

gh stack submit exits with an error when the git remote URL uses a custom SSH host alias (e.g. github.com-work) instead of the literal github.com hostname. There is no flag to override the repository, so submit is unusable in this configuration.

Steps to reproduce

  1. Configure ~/.ssh/config with a host alias (common for multi-account setups):

    Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work

  2. Clone using the alias:

    git clone git@github.com-work:org/repo.git
cd repo

    git remote get-url origin → git@github.com-work:org/repo.git

  3. Initialize a stack and submit:

    git checkout -b layer-1 && git commit --allow-empty -m "layer 1"
git checkout -b layer-2 && git commit --allow-empty -m "layer 2"
git checkout layer-1
gh stack init --adopt -b main layer-1 layer-2
gh stack submit --draft

Actual result

✗ failed to create GitHub client: determining repository: unable to determine current
repository, none of the git remotes configured for this repository point to a known
GitHub host

The --remote origin flag and GH_HOST=github.com env var do not help — the error
is identical with both.

Expected result

gh stack submit pushes the branches and opens draft PRs, the same as it would with a git@github.com:org/repo.git remote.

What I tried

  • gh stack submit --remote origin — same error
  • GH_HOST=github.com gh stack submit — same error
  • GH_REPO=org/repo gh stack submit — gets past host detection, but then pushes to
    git@github.com:org/repo.git instead of the configured alias, so the push fails
    with a key-agent rejection

Workaround

Push branches manually and create PRs one at a time:

git push origin layer-1 layer-2
gh pr create --draft --repo org/repo --base main   --head layer-1 --title "layer 1"
gh pr create --draft --repo org/repo --base layer-1 --head layer-2 --title "layer 2"

Environment

gh version 2.89.0 (nixpkgs)
gh extension: gh stack (github/gh-stack)
OS: macOS
Remote URL format: git@github.com-<alias>:org/repo.git

Activity

  1. skarim
    added
    bugBug Reports
    topic: cli - submit`gh stack submit`: remote/SSH handling, config flags, draft PRs, and submit UX or failures.
    on Jul 23, 2026

  2. benekuehn commented on Jul 30, 2026

    @benekuehn
    benekuehn
    on Jul 30, 2026

    I opened an upstream fix in cli/go-gh#274. The root cause is in repository.Current: it translates SSH alias URLs, but continues filtering with cached repository metadata from before translation. The PR refreshes that metadata while preserving fetch/push precedence and includes a regression test for the github.com-work case.

    This will still need to merge and then be consumed by gh-stack before the issue is resolved.

  3. RishabJaiswal commented on Aug 3, 2026

    @RishabJaiswal
    RishabJaiswal
    on Aug 3, 2026

    Facing the same.
    It quite a common usecase when a user has multiple github account

  4. albinofreitasrunflow commented on Aug 6, 2026

    @albinofreitasrunflow
    albinofreitasrunflow
    on Aug 6, 2026

    Hit this today with the same multi-account setup (Host github.com-<org> → HostName github.com in ~/.ssh/config).

    One data point that may help scope the fix: the core gh CLI resolves the alias fine — gh repo view and gh pr list correctly identify the repository with only the aliased remote configured. It's only the extension that fails with unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host, so it looks like the alias translation that gh does via ssh -G/~/.ssh/config isn't wired up in the extension's remote resolution.

    Workaround we're using: add a second HTTPS remote (git remote add ghstack https://github.com/org/repo.git) and pass --remote ghstack to submit/push/sync/rebase. Two gaps remain with that workaround:

    • checkout <stack-number>, trunk, and modify accept no --remote flag, and with two remotes and no remote.pushDefault they fail non-interactively.
    • Setting remote.pushDefault to the HTTPS remote fixes those but reroutes plain git push away from the SSH remote, which defeats the per-repo identity pinning that motivates the alias setup in the first place.

    Translating aliases the same way the core CLI does would make the extension work out of the box for multi-account users.

  5. benekuehn commented on Aug 6, 2026

    @benekuehn
    benekuehn
    on Aug 6, 2026

    Thanks @albinofreitasrunflow.

    Translating aliases the same way the core CLI does would make the extension work out of the box for multi-account users.

    I think that's the wrong way. It's just putting again a patch over the shortcoming of go-gh and wouldn't solve it for other consumers hence my proposal cli/go-gh#274.

  6. metalelf0 commented on Sep 24, 2026

    @metalelf0
    metalelf0
    on Sep 24, 2026

    Workaround: choose the SSH key by directory, not by host alias

    gh-stack reads the host from the remote URL. A remote like git@work:org/repo doesn't point to a known GitHub host, so it fails. Fix: point remotes at plain github.com and let git choose the SSH key per directory with core.sshCommand.

    1. Set the key for each identity (~/.gitconfig; the work include goes last so it wins):

    [include]
	path = ~/.gitconfigs/personal
[includeIf "gitdir:~/code/myCompany/"]
	path = ~/.gitconfigs/work

    ~/.gitconfigs/personal:

    [core]
	sshCommand = ssh -i ~/.ssh/id_ed25519_personal -o IdentitiesOnly=yes

    ~/.gitconfigs/work:

    [core]
	sshCommand = ssh -i ~/.ssh/id_ed25519_mycompany -o IdentitiesOnly=yes

    IdentitiesOnly=yes stops ssh from offering the other account's key first.

    2. Remove insteadOf rules that rewrite github.com back to the alias. Find them with git config --global --get-regexp '^url\.'. For example:

    # remove this! Don't blindly copy and paste it :) 
[url "git@work:myCompany/"]
	insteadOf = git@github.com:myCompany/

    3. Update remotes:

    git remote set-url origin git@github.com:myCompany/repo.git

    4. Verify:

    git ls-remote origin HEAD
gh stack submit --draft

    The gh API account is separate from the SSH key. If you're logged in with more than one account, run gh auth switch before submitting, or set GH_TOKEN per directory.

  7. williammartin
    added 2 commits that reference this issue on Oct 8, 2026

    fix: refresh repository identity after SSH translation

    862ad72

    fix: refresh repository identity after SSH translation

    c04dd5f
  8. skarim
    closed this as completedin #554on Oct 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

    bugBug Reportstopic: cli - submit`gh stack submit`: remote/SSH handling, config flags, draft PRs, and submit UX or failures.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions