gh stack link --remote <fork> queries the fork’s parent repository

Start by reproducing gh stack link --base main --remote fork --open <first-pr> <second-pr> in the multi-remote fork setup, then inspect repository resolution and the .git/gh-stack state. Done means the command uses the fork endpoint, and conflicting repository signals fail before an API request with a clear selection error; add a regression test for this scenario.

Summary

In a fork clone with separate upstream and fork remotes, gh stack link --remote fork queries the stack API for the upstream parent repository instead of the selected fork.

This prevents linking existing PRs when access to the parent is restricted, even though the authenticated user can access the fork and all PRs being linked have both their base and head repositories in the fork.

This appears related to #381, but that report covers gh stack submit selecting origin in a multi-remote clone. This reproduction covers gh stack link, has no origin remote, and shows the extension selecting a fork's parent despite an explicit --remote, remote.pushDefault, and gh-resolved repository.

Environment

• gh version 2.100.0 (2026-09-03)
• gh stack / github/gh-stack v0.1.1
• Repository: <fork-owner>/<repository>, a fork of <upstream-owner>/<repository>
• Two existing PRs whose base and head repositories are both the fork

Repository configuration

$ git remote -v
fork        git@github.com:<fork-owner>/<repository>.git (fetch)
fork        git@github.com:<fork-owner>/<repository>.git (push)
upstream    git@github.com:<upstream-owner>/<repository>.git (fetch)
upstream    no_push (push)

$ git config --get remote.pushDefault
fork

$ git config --get remote.fork.gh-resolved
<fork-owner>/<repository>

$ gh repo set-default --view
<fork-owner>/<repository>

The local .git/gh-stack state was initialized with the parent repository despite this configuration:

{
  "schemaVersion": 1,
  "repository": "github.com:<upstream-owner>/<repository>"
}

Steps to reproduce

1. Clone a GitHub fork with one remote for the fork and a separate fetch-only remote for its parent. There is no origin remote.

2. Set the fork as the push/default GitHub repository:

   git config remote.pushDefault fork
   git config remote.fork.gh-resolved <fork-owner>/<repository>
   

3. In the fork, create two open PRs intended to form a stack. Both PRs have base and head repositories equal to <fork-owner>/<repository>.

4. Run:

   gh stack link --base main --remote fork --open <first-pr> <second-pr>
   

Actual behavior

The extension calls the parent repository's stack endpoint and fails:

Checking existing stacks...
failed to list stacks: HTTP 403
(https://api.github.com/repos/<upstream-owner>/<repository>/stacks?per_page=100&page=1)

The authentication failure is expected for that parent repository. The unexpected behavior is querying the parent at all.

Expected behavior

gh stack link --remote fork should query and mutate stack metadata in <fork-owner>/<repository>, matching:

• the explicitly selected remote;
• remote.pushDefault;
• standard gh repository resolution; and
• the base/head repository of every PR passed to --open.

If these signals disagree, the extension should fail before making an API request and report which repository needs to be selected.

Controls

The correct fork endpoint is accessible with the same authentication:

gh api 'repos/<fork-owner>/<repository>/stacks?per_page=100&page=1'
# HTTP 200

Running the same link command from a temporary Git repository whose only remote is <fork-owner>/<repository> succeeds:

Created stack with 2 PRs

This isolates the failure to repository resolution in the multi-remote fork clone rather than authentication, PR shape, or stack creation.

Impact

• gh stack link cannot be used normally in this fork/multi-remote layout.
• Users may receive misleading authentication errors for a repository they did not select.
• Where the user has access to both repositories, the command may read or write stack metadata in the wrong repository.

Workaround

Run gh stack link from a temporary repository configured with only the fork remote. This is error-prone and loses the normal relationship with the working clone.

Related

• #381 reports the likely shared repository-resolution defect for gh stack submit.
• #461 reports stale fork/parent metadata affecting gh stack submit after a remote rename.

If maintainers consider link covered by #381, I am happy for this to be closed as a duplicate; the additional reproduction may still be useful for a regression test.