stack submit reports success (push + PR creation) without actually doing either, when origin remote is an old/renamed repo name

Comienza en el punto de entrada gh stack submit y reproduce el caso de un origen renombrado utilizando los comandos y las comprobaciones de git ls-remote del issue. Sigue los resultados del push y de la creación de PR a través de la ruta de resolución de GitHub, comparándolos con el repositorio canónico y con el caso del repositorio de trabajo. Se considera terminado cuando las operaciones fallidas devuelven un error y no pueden producir una salida de éxito que afirme que se crearon ramas y PRs.

Environment

• gh version 2.96.0 (2026-07-02)
• gh-stack v0.1.0
• macOS/Linux (bash), two sibling repos in the same GitHub org, one hit the bug and one didn't with the exact same command sequence

Summary

gh stack submit printed full success output — branches pushed, 3 PRs created, a "Stack #478" created — but none of it actually happened on GitHub. The branches were never updated on origin, and no PRs existed anywhere I could find them. A second repo in the same session, using the identical workflow, worked correctly.

Repro shape

• Repo A (worked correctly): plain repo, origin is the canonical name of the repo on GitHub.
• Repo B (bug): origin remote (git@github.com:<org>/<old-repo-name>.git) is an old/renamed name — GitHub transparently redirects gh api repos/<org>/<old-repo-name> and gh repo view to the current canonical name. The canonical repo also happens to carry stale fork/parent metadata pointing at an unrelated third repo (from some past history), though I'm not sure that part is relevant.

Steps, same in both repos:

gh stack init --base <trunk> branchA branchB branchC   # adopts 3 existing local commits, one per branch
gh stack submit

In Repo A, gh stack submit output:

Checking stack state...
Pushing to origin...
✓ Created PR #N1 for branchA
✓ Created PR #N2 for branchB
✓ Created PR #N3 for branchC
✓ Stack created on GitHub with 3 PRs (stack #N4)
✓ Pushed and synced 3 branches

...and this was true — git ls-remote --heads origin showed the branches updated, and gh pr view N1 etc. resolved to real, correctly-based PRs.

In Repo B, gh stack submit printed the exact same shape of success output (different PR numbers), but:

• git ls-remote --heads origin afterward showed the three branches unchanged — branchB (the one branch that existed before stack init, now rewritten to a different commit locally) was still pointing at its old pre-rewrite SHA on origin. branchA and branchC didn't exist on origin at all.
• The claimed PR numbers didn't correspond to any real PR: gh pr view <N1> against the repo (by its canonical resolved name, by the old renamed name, and by the stale fork-parent repo) all failed with "Could not resolve to a PullRequest". gh pr list --head branchA (all three variants of repo name) returned [].
• A second, unmodified gh stack submit run reported PR #N1 is up to date / ✓ Stack on GitHub is up to date with 3 PRs / ✓ Pushed and synced 3 branches — again fully green, again not reflecting reality.

Workaround

Plain git push -f origin branchA branchB branchC (outside gh-stack) worked immediately and updated origin correctly. Manually running gh pr create --repo <canonical-name> --base ... --head ... for each of the 3 layers created real, correctly-stacked PRs. After that, gh stack view correctly picked up the manually-created PRs (via head-branch matching, presumably) and rendered a consistent stack — so the local stack metadata itself wasn't corrupted, only submit's push+create step silently no-op'd while reporting success.

Impact

This is a correctness/trust issue rather than a crash: there's no error, no non-zero exit code (that I checked), and no indication anything is wrong — gh stack submit reports the same "everything succeeded" shape whether or not it actually did anything. Anyone scripting around this or trusting the CLI output at face value would believe their PRs are live when they aren't.

Suspected cause

Possibly a repo-resolution issue: pushing/creating against a stale resolved repo identity (following the old→canonical rename, or the stale fork/parent link) that either 404s silently or targets a repo the invoking user doesn't actually have write access to, without the tool checking the actual API response before printing ✓.

Happy to provide more repro detail/logs if useful — this was found mid-task rather than in an isolated repro, so I don't have a minimal standalone case yet, but the shape above (rename + fork-parent metadata) is the one differentiating factor I found between the working and failing repo.