An upstream PR cannot use a fork branch as its base, even with write access to both repos

Start by reproducing the cross-fork behavior with gh stack submit and gh stack link --remote, then review related issues #46, #496, and #509 for existing constraints. Done means a single-fork stack can target upstream, including adding a layer to an already-open cross-fork PR, while preserving ordinary permissions and review behavior.

Problem

Stacked PRs require every branch in a stack to live in the same repository — the docs state: "Stacked pull requests require all branches to be in the same repository. Cross-fork stacks are not supported."

This is not a permissions problem. I have write access to both the upstream repository and my fork. The blocker is the fork boundary itself: even with full access on both sides, a stack cannot start in a fork and land in upstream.

---

The workflow that does not work

1. Fork upstream → origin.
2. Create feature-a and push it to origin.
3. Open a PR: origin:feature-a → upstream:main. This works today — it is an ordinary cross-fork PR.
4. Stack feature-b on top of feature-a, push it to origin.
5. Now I want that second PR to join the stack of the PR from step 3, in upstream.

Step 5 has nowhere to go:

• A PR opened in upstream must have a base ref that exists in upstream. There is no way to express "base = origin:feature-a" for a PR that lives in upstream, so the upper layers of the stack have no home in the repository where the stack needs to be reviewed.
• Opening origin:feature-b → origin:feature-a instead puts that PR in the fork's PR list, split off from the step-3 PR. The two are not one stack, and upstream reviewers never see the layering.

So the stack I want is:

PR #3: origin/feature-c → origin/feature-b      ┐
PR #2: origin/feature-b → origin/feature-a      ├─ one stack, reviewed in upstream
PR #1: origin/feature-a → upstream/main         ┘

and this cannot be created, in either repository.

---

Incremental stacking on an already-open PR

The second half of this is just as important: the stack is usually not planned up front. I open a single cross-fork PR first, keep working, and only later realize the next change belongs on top of it.

So it should be possible to take an already-open cross-fork PR (origin:feature-a → upstream:main) and attach a new layer to it afterwards, turning it into the bottom of a stack — rather than having to decide at creation time that this PR will be stacked, or having to tear down and recreate the existing PR.

---

Why this matters

Forking is not only the OSS drive-by contribution path — it is also a normal way to work when you do have access on both repositories: keeping topic branches out of the shared repo, working across an org boundary, or simply following a project's convention that all branches live in personal forks.

Right now the two features are mutually exclusive. If branches live in a fork, stacked PRs are unavailable; to use stacked PRs, every branch has to be pushed into upstream directly. That forces a choice between the fork-based branch layout and the ability to present work as reviewable layers.

For scale, from Octoverse 2025: 63% of all repositories on GitHub are open source or public, and 518.7M pull requests were merged across public and open source repositories in 2025 (+29% YoY). Every project whose branches live in forks is currently outside the reach of stacked PRs.

---

Proposed behavior

Allow a stack whose branches all live in a single fork, with the bottom-most PR targeting upstream:

origin/feature-a → upstream/main
origin/feature-b → origin/feature-a
origin/feature-c → origin/feature-b

treated as one stack in the upstream repository, with the existing permission and review model unchanged — each PR is still an ordinary cross-fork PR reviewed and merged by upstream — and no change to the underlying Git branch model.

Supporting stacks that span multiple forks (basing work on another contributor's open PR) would be a reasonable later step, but single-fork → upstream covers the common case.

---

Related reports

The request has come up repeatedly, and has been acknowledged, but has not shipped:

• #18 (discussion, 2026-04-13) — "Stacked PRs with branches across forks", opened the day the private preview started: "without this it's not very useful yet."
• #46 — "FR: support for cross-fork stacked PRs" (2026-04-16). @skarim replied on 2026-04-17: "support for Stacked PRs across forks will be coming in a future update! ... it is a high priority for us and on our roadmap", describing the single-fork → upstream shape as the first step. Repeated +1s and ETA requests since, with no further update.
• #509 (2026-09-13) — gh stack submit on a fork still fails on v0.1.1, resolving the stack against the upstream parent instead of the fork: Head sha can't be blank, Base sha can't be blank, ... Head ref must be a branch. gh repo set-default <fork> does not change it.
• #496 — gh stack link --remote <fork> queries the fork's parent repository.
• community#201439 — the public preview announcement thread, where several people raised cross-fork support as the blocking gap.

Five months after the roadmap confirmation, the v0.1.0 (2026-07-29) and v0.1.1 (2026-09-02) release notes contain no cross-fork work, and reports against the current release are still arriving (#509, two days ago).

I am filing this separately from #46 because the existing threads frame cross-fork stacking as an access problem for contributors who cannot push to upstream. The case above is reproducible with write access to both repositories, and it also covers attaching a stack to a cross-fork PR that is already open — which I did not see raised elsewhere. Happy for this to be folded into #46 if you would rather track it there.

---

Ask

Where do cross-fork stacks currently sit on the roadmap, and is there a target release for the single-fork → upstream case? Happy to test a preview build.