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.
Environment
Summary
gh stack submitprinted 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 onorigin, and no PRs existed anywhere I could find them. A second repo in the same session, using the identical workflow, worked correctly.Repro shape
git@github.com:<org>/<old-repo-name>.git) is an old/renamed name — GitHub transparently redirectsgh api repos/<org>/<old-repo-name>andgh repo viewto the current canonical name. The canonical repo also happens to carry stalefork/parentmetadata pointing at an unrelated third repo (from some past history), though I'm not sure that part is relevant.Steps, same in both repos:
In Repo A,
gh stack submitoutput:...and this was true —
git ls-remote --heads originshowed the branches updated, andgh pr view N1etc. resolved to real, correctly-based PRs.In Repo B,
gh stack submitprinted the exact same shape of success output (different PR numbers), but:git ls-remote --heads originafterward showed the three branches unchanged —branchB(the one branch that existed beforestack init, now rewritten to a different commit locally) was still pointing at its old pre-rewrite SHA onorigin.branchAandbranchCdidn't exist onoriginat all.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[].gh stack submitrun reportedPR #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 updatedorigincorrectly. Manually runninggh pr create --repo <canonical-name> --base ... --head ...for each of the 3 layers created real, correctly-stacked PRs. After that,gh stack viewcorrectly 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, onlysubmit'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 submitreports 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.