`gh stack` resolves the API repository from the `origin` remote, ignoring `--remote`, `gh repo set-default`, and its own state file — silently operating on the wrong repository in multi-remote clones

Comienza rastreando la resolución del repositorio desde los puntos de entrada gh stack init y gh stack submit, incluidos --remote, GH_REPO, gh-resolved y el campo repository en .git/gh-stack. Compara el repositorio seleccionado con el remoto de push y verifica que los flujos interactivos y --auto apunten al repositorio previsto o fallen explícitamente cuando la resolución sea ambigua.

Summary

In a clone with multiple remotes, every gh stack PR/stack API operation is bound to the repository of the origin remote, regardless of:

• the --remote flag (which only changes the push target),
• gh repo set-default / remote.<name>.gh-resolved (the standard gh CLI repo resolution),
• the repository field in .git/gh-stack (editing it has no effect on subsequent runs).

If origin points at a different repository than the one your branches and PRs live in — the completely standard fork workflow where origin is upstream and you push to your fork — gh stack submit pushes to the right remote but then tries to create PRs and stacks on the wrong repository. In --auto / non-interactive mode this happens silently: there is no "Multiple remotes found" prompt (the interactive path in #219 at least shows one).

In my case the only reason no PRs were actually opened against the upstream project is that my branches don't exist there, so every createPullRequest failed. If upstream had happened to contain same-named branches, gh stack submit --auto would have opened a pile of PRs against a repository I never pointed it at. For agent/scripted use this is a dangerous default.

Environment

• gh version 2.96.0
• gh-stack v0.1.0
• Clone with 7 remotes; origin = github.com/argoproj/argo-workflows (upstream), joibel = github.com/Joibel/argo-workflows (fork, where all stack branches and 8 open PRs live)
• gh repo set-default Joibel/argo-workflows is set (remote.joibel.gh-resolved = base)

Steps to reproduce

1. Clone a repo with origin pointing at upstream and a second remote pointing at your fork.
2. Create branches with open PRs on the fork (head and base both on the fork).
3. gh stack init --base <trunk> <branch1> ... <branchN> — adopts the branches fine, but records "repository": "github.com:<origin-owner>/<repo>" in .git/gh-stack.
4. gh stack submit --remote <fork-remote> --auto

Observed

• Push goes to the fork remote correctly ("Pushing to joibel... ✓ Pushed and synced 8 branches").

• All PR operations target the origin repository: existing fork PRs are not detected, and the extension attempts createPullRequest against upstream, failing with:

  ⚠ failed to create PR for <branch>: creating PR: GraphQL: Head sha can't be blank,
  Base sha can't be blank, No commits between <base> and <branch>,
  Head ref must be a branch, Base ref must be a branch (createPullRequest)
  

  (Same error signature as #219, different root cause — here the refs genuinely don't exist because it's querying the wrong repository.)

• The interactive TUI confirms it: the header shows Repo: argoproj/argo-workflows even when invoked with --remote joibel.

• None of the following change the target repository: --remote, gh repo set-default, editing the repository field in .git/gh-stack.

Workaround

GH_REPO=<fork-owner>/<repo> gh stack submit --remote <fork-remote> --auto works perfectly — existing PRs are detected ("PR #NN for is up to date") and the stack is created.

Expected

• Repo resolution should follow the standard gh CLI rules (GH_REPO, then gh-resolved/gh repo set-default, then remote heuristics), or at minimum follow the remote selected with --remote, since a stack's branches and PRs must by definition (#46) live in the repository the branches are pushed to.
• If resolution is ambiguous in non-interactive mode, fail with an explicit "multiple remotes, specify GH_REPO or --remote" error rather than silently picking origin.
• gh stack init should surface/validate which repository it bound the stack to.

Related

• #219 — same GraphQL error signature via a different resolution failure; its interactive run at least got a "Multiple remotes found" prompt, which --auto skips.
• #45, #337 — same code area (deriving the API repo from remote URLs) tripping on SSH aliases / hostname remaps.
• #46 — cross-fork stacks; confirms head+base must be one repository, which makes binding to origin doubly wrong when pushes go elsewhere.