gh stack submit falsely reports stack recreation when no replacement stack is persisted

Start with the gh stack submit flow and reproduce the reported state using the uncached gh api checks for the stack and an open PR. Trace stack recreation through remote persistence and local .git/gh-stack updates. Done means failures return non-zero, while success is printed only after the replacement stack and expected PR membership are verified.

Summary

gh stack submit reports that a modified stack was successfully recreated on GitHub, but no replacement stack exists afterward.

Branches and PR bases are pushed successfully. Open PRs become unstacked, local metadata retains the old closed stack ID, and the command still exits with success output.

Environment

• gh version 2.97.0
• gh stack version 0.1.0
• macOS 26.6
• Repository has GitHub Stacks enabled

Setup

Existing remote stack:

• One merged bottom PR
• Multiple open PRs
• One closed PR in the middle

Locally:

1. Check out remote stack.
2. Run gh stack modify.
3. Drop the closed middle PR.
4. Resolve cascading rebase conflicts.
5. Run gh stack submit.

Actual output

Found the stack on GitHub — updating it to match your local stack
Merged PRs have left the stack on GitHub, so it wasn't updated — your unmerged PRs were pushed and re-based onto the trunk
✓ Stack recreated on GitHub to match local state
✓ Pushed and synced 47 branches

Actual remote state

The branches were pushed, but no replacement stack was created.

Repeated uncached API checks showed:

gh api -H 'Cache-Control: no-cache' \
  repos/OWNER/REPO/pulls/OPEN_PR \
  --jq '.stack'

Result:

null

Listing repository stacks showed only the old closed stacks:

gh api -H 'Cache-Control: no-cache' \
  'repos/OWNER/REPO/stacks?per_page=100'

The old stack remained closed with only its merged PR. No new stack number appeared.

This was checked three times over 12 seconds. Direct PR membership and the stack list remained unchanged.

Local .git/gh-stack still referenced the old closed stack number and ID.

Expected behavior

One of:

1. A replacement remote stack is persisted and local metadata is updated to its new number and ID.
2. Stack creation failure is reported with a non-zero exit code.

The command must not print:

✓ Stack recreated on GitHub to match local state

unless the remote stack exists and its PR membership has been verified.

Impact

• User believes stack recreation succeeded.
• GitHub UI contains no open stack.
• Every open PR has stack: null.
• Local metadata points to a closed historical stack.
• Subsequent checkout, sync, and modify operations begin from inconsistent state.

Suggested safeguard

After creating or recreating the stack:

1. Read the returned stack ID and number.
2. Query the stack or one member PR.
3. Verify expected membership.
4. Only then persist local metadata and print success.

If verification fails, retain recovery state and return an error.