push_to_pull_request_branch cannot update fork PRs after PR-context checkout

[dsyme]

Summary

In a maintainer-triggered PR /repo-assist (issue_comment) run against a fork PR, gh-aw successfully checks out the fork head via refs/pull/<N>/head, but push_to_pull_request_branch cannot generate its incremental patch because it requires refs/remotes/origin/<head.ref>.

Run: https://github.com/fsprojects/Paket/actions/runs/33002971793
PR: fsprojects/Paket#4323
Compiled with gh-aw v0.86.2.

Reproduction

PR #4323 is cross-repository:

• base: fsprojects/Paket:master
• head: nicholi/Paket:feature/native_versions
• head SHA at the run: dbc69e77bc96a989973ec55c2a0bddfd3e8e63bf

The workflow has:

checkout:
  fetch: ["*"]
  fetch-depth: 0

The checkout step correctly detected the fork and fetched:

+refs/pull/4323/head:refs/remotes/origin/pr-head

It then created local branch feature/native_versions from origin/pr-head. The agent committed its change locally and made a corrected safe-output call:

safeoutputs push_to_pull_request_branch

with repo: fsprojects/Paket, pull_request_number: 4323, and branch: feature/native_versions.

The call failed synchronously:

Cannot generate incremental patch: refs/remotes/origin/feature/native_versions is not present in checkout ... Add "feature/native_versions" to the workflow's checkout.fetch list so the branch is fetched during setup.

No push_to_pull_request_branch item was persisted because MCP patch generation failed before recording the write intent. The agent subsequently emitted report_incomplete, which was the only message processed by the downstream safe_outputs job.

Root cause

actions/setup/js/checkout_pr_branch.cjs handles fork PRs by fetching the correct PR tip to origin/pr-head and checking out a local branch named from pulls.get(...).head.ref.

Incremental patch generation in actions/setup/js/generate_git_patch.cjs instead calls ensureOriginRemoteTrackingRef(branchName) and requires origin/<branchName> as its base.

For a fork PR, checkout.fetch refspecs operate on the base repository's origin. Therefore fetch: ["*"] can only fetch fsprojects/Paket branches and cannot create origin/feature/native_versions from nicholi/Paket. The current remediation text is not actionable for fork PRs.

There is also a correctness risk if the base repository happens to have a same-named branch: wildcard fetch can populate origin/<head.ref> from the wrong repository, causing incremental patch generation to use the wrong base commit.

Expected behavior

For a trusted maintainer-triggered PR-context workflow, the already-fetched refs/pull/<N>/head commit should be available as the incremental base for push_to_pull_request_branch, including when the PR comes from a fork. checkout.fetch should not need to name a fork branch.

The downstream push handler can continue using PR API metadata and its authenticated fork-aware push path; patch generation only needs an unambiguous local ref/SHA representing the PR tip before the agent's commits.

Suggested direction

Pass or persist an explicit PR-head baseline (for example the fetched origin/pr-head SHA) for incremental patch generation instead of inferring it from origin/<head.ref>. Avoid aliasing to origin/<head.ref> unless all consumers can distinguish the head repository, because that namespace normally represents the base repo remote.

Also update the error so it does not claim the safe-outputs server lacks credentials for a public fork or recommend checkout.fetch when the missing ref belongs to a fork.

Regression coverage

• issue_comment /repo-assist on a fork PR, with fetch: ["*"] and fetch-depth: 0
• fork PR whose head branch does not exist in the base repo
• fork PR whose head branch name also exists in the base repo, proving the fork PR tip is used
• corrected push_to_pull_request_branch call generates an incremental patch from the pre-agent PR tip and is persisted for downstream processing

[dsyme]

The problem persists after #56119. Reopening based on a new fork-PR run that used current main.

New run: https://github.com/fsprojects/Paket/actions/runs/33070448438
PR: fsprojects/Paket#4321

The compiled workflow used:

• compiler v0.87.4-375-g6288b259e4
• setup action github/gh-aw/actions/setup@6288b259e4

So this is not a stale lock file; it includes merge commit 590ce270354e1beffe2d943660087cabc24ca2c8 from #56119.

What happened

Checkout correctly fetched and checked out the fork head:

git fetch origin +refs/pull/4321/head:refs/remotes/origin/pr-head
git checkout -B artifactory-empty-dependencies origin/pr-head

PR metadata:

• base: fsprojects/Paket:master
• head: Desarc/Paket:artifactory-empty-dependencies
• head SHA: d98e779eaf8e556d1045164f4bba9438d1cceeb5

The agent committed its change locally and called push_to_pull_request_branch with the correct target:

{
  "branch": "artifactory-empty-dependencies",
  "pull_request_number": 4321,
  "repo": "fsprojects/Paket"
}

It still fell back to origin/<branch> and failed:

Cannot generate incremental patch: refs/remotes/origin/artifactory-empty-dependencies is not present ...

The later retry with repo: Desarc/Paket was rejected with Repository 'Desarc/Paket' is not in the allowed-repos list. Allowed: fsprojects/Paket. That rejection is expected: the safe-output target is PR #4321 in fsprojects/Paket; the handler should derive and push to the PR's fork head after accepting the base-repo PR target.

Remaining root cause

#56119 exports the recorded baseline from checkout_pr_branch.cjs using:

GH_AW_PR_HEAD_BASE_BRANCH
GH_AW_PR_HEAD_BASE_SHA
GH_AW_PR_HEAD_BASE_REPO
GH_AW_PR_HEAD_BASE_PR_NUMBER
GH_AW_PR_HEAD_BASE_REF

However, the compiled MCP gateway launch command does not forward any of these variables into the awmg-mcpg container. The nested safeoutputs server config also does not include them in its env map.

Therefore safe_outputs_handlers.cjs, which reads these values from process.env, never sees the recorded baseline and silently takes the old origin/<branch> fallback.

The missing wiring is visible in the generated workflow around the MCP gateway setup:

1. the outer gateway docker run ... -e ... list omits all GH_AW_PR_HEAD_BASE_* variables;
2. the nested safeoutputs MCP server env object omits them too.

The fix needs to forward the five variables across both container boundaries, with a compile/integration regression test that asserts the generated lock YAML contains them in both places. The existing handler-only tests set process.env directly and therefore did not exercise this boundary.

[dsyme]

Follow-up validation for #56341:

Run https://github.com/fsprojects/Paket/actions/runs/33074154008 proves the remaining bug reported here is fixed: the compiled workflow forwarded all five GH_AW_PR_HEAD_BASE_* variables across the outer MCP gateway and nested safeoutputs containers; the MCP handler used the recorded PR-head SHA d98e779eaf8e556d1045164f4bba9438d1cceeb5, generated an incremental patch and bundle, and persisted push_to_pull_request_branch. It no longer falls back to missing origin/artifactory-empty-dependencies.

Application subsequently rejected the write because the PR head is contributor fork Desarc/Paket and Paket has neither an exact configured head-repo nor a credential with write access to that fork. That rejection is intentional under the existing safe-output specification, which forbids arbitrary contributor forks as write targets; it is not the baseline propagation defect.

A second run after Paket migrated its memory schema completed green: https://github.com/fsprojects/Paket/actions/runs/33076542465. It reported the external-fork limitation through report_incomplete, validated and published repo memory, and completed conclusion reporting successfully.

PR #56341 now includes targeted renderer, integration, formal checkout, and WASM golden coverage and has been updated with current main.