Fork-backed create_pull_request fails with duplicate Authorization HTTP 400

[bryanchen-d]

Summary

Fork-backed create_pull_request fails every git operation against head-repo with HTTP 400 when head-github-app supplies a separate fork token.

This appears to be the create_pull_request fork equivalent of #40280: the safe-output checkout retains the upstream repository's persisted http.https://github.com/.extraheader, while the fork path supplies head-github-token separately. Git sends duplicate/conflicting Authorization headers to the fork remote.

Environment

• gh-aw compiler/setup: v0.83.1
• create-pull-request.target-repo: microsoft/vscode
• create-pull-request.head-repo: bryanchen-d/vscode
• upstream credential: safe-outputs.github-app
• fork credential: create-pull-request.head-github-app
• runner: ubuntu-slim

safe-outputs:
  github-app:
    client-id: ${{ steps.kv-app.outputs.client-id }}
    private-key: ${{ steps.kv-app.outputs.pem }}
    owner: microsoft
    repositories: [vscode]
  create-pull-request:
    target-repo: microsoft/vscode
    head-repo: bryanchen-d/vscode
    allowed-repos: [microsoft/vscode, bryanchen-d/vscode]
    head-github-app:
      client-id: ${{ steps.kv-app.outputs.client-id }}
      private-key: ${{ steps.kv-app.outputs.pem }}

Observed

The head token mints successfully for exactly bryanchen-d/vscode. The handler generates a valid patch/bundle, then direct git push and its fallbacks fail with:

fatal: unable to access 'https://github.com/bryanchen-d/vscode.git/':
The requested URL returned error: 400

No fork branch is created. With fallback-as-issue: true, the handler creates a fallback issue and the workflow reports success.

Controlled probe

A temporary job minted a token from the same App key with the same scope:

owner: bryanchen-d
repositories: vscode
permission-contents: write

Using that token in the same runner/job:

1. GitHub REST API ref create/delete succeeded.
2. Plain git fetch succeeded.
3. Plain git push creating a disposable fork branch succeeded.
4. Plain git push deleting that branch succeeded.

The probe branch was deleted. This rules out App installation, repository selection, and effective contents-write permission.

Suspected code path

Current create_pull_request.cjs temporarily calls overridePersistedExtraheader(...) for ls-remote, then restores the upstream checkout header before pushSignedCommits(...) receives pushRemoteUrl plus the separate pushToken.

For a fork-backed PR, the persisted upstream header and fork credential must not both reach the fork request. The fork token should temporarily replace the persisted header for the entire fork remote operation, or the push should otherwise use exactly one Authorization source.

Expected

Fork branch is pushed with only the head-github-app token, then the upstream token creates the PR in target-repo.

Related

• Duplicate 'Authorization' header (HTTP 400) on git ops in push_to_pull_request_branch safe output #40280 fixed duplicate Authorization headers for push_to_pull_request_branch.
• Support fork-backed pull requests in safe outputs #45836 added fork-backed PR support.

[bryanchen-d]

Reproduction after rebasing onto microsoft/vscode-engineering#3364 and recompiling with gh-aw v0.83.3: https://github.com/microsoft/vscode-engineering/actions/runs/30289234348

The failure persists and now shows the exact duplicate-header accumulation in the safe_outputs log:

Resolved head repository: bryanchen-d/vscode
git ls-remote --heads https://github.com/bryanchen-d/vscode.git ...
remote: Duplicate header: "Authorization"
git_auth_helpers: restoring 1 previous extraheader value(s)
...
remote: Duplicate header: "Authorization"
git_auth_helpers: restoring 2 previous extraheader value(s)
...
remote: Duplicate header: "Authorization"
git_auth_helpers: restoring 3 previous extraheader value(s)
...
git push https://github.com/bryanchen-d/vscode.git ...
remote: Duplicate header: "Authorization"
git_auth_helpers: restoring 4 previous extraheader value(s)

The helper's read/restore cycle grows the persisted multi-valued key on every retry. The same App token succeeds in a controlled plain-git push/delete probe, so this remains isolated to the handler's extraheader override/restore logic.