v0.83.5: fork create_pull_request still sends duplicate Authorization headers

[bryanchen-d]

Summary

The fix released in v0.83.5 for #48414 does not prevent duplicate Authorization headers in fork-backed create_pull_request.

The runtime contains withGitHubHostToken, but the first fork git ls-remote still fails with:

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

The restore loop then accumulates another visible value on every attempt (read 1, then 2, 3, 4).

Environment

• gh-aw compiler: v0.83.5
• gh-aw-actions/setup: 696e63acbcc80e7cb5604653ee12014762d100e4 (v0.83.5)
• Fix from fix: wrap fork push sequences in withGitHubHostToken to prevent duplicate Authorization (HTTP 400) #48595 is present in setup/js/create_pull_request.cjs
• target-repo: microsoft/vscode
• head-repo: bryanchen-d/vscode
• separate safe-outputs.github-app and create-pull-request.head-github-app

Reproduction

Workflow run: https://github.com/microsoft/vscode-engineering/actions/runs/30472145297

Relevant sequence from the first attempt:

git_auth_helpers: read 1 existing extraheader value(s)
git_auth_helpers: overriding http.https://github.com/.extraheader with CI trigger token
git config --replace-all http.https://github.com/.extraheader Authorization: basic ***
git_auth_helpers: extraheader override applied
git ls-remote --heads https://github.com/bryanchen-d/vscode.git ...
remote: Duplicate header: "Authorization"
git_auth_helpers: restoring 1 previous extraheader value(s)

Subsequent operations report read 2, read 3, and read 4, and all fail with the same duplicate-header HTTP 400.

No fork branch or PR is created; fallback-as-issue produces an issue instead.

Expected

withGitHubHostToken should ensure exactly one effective Authorization source and restoration should return to the original cardinality.

Analysis

getExtraheaderValues reads effective values with unscoped git config --get-all, while overridePersistedExtraheader and restorePersistedExtraheader write through the repository-local default scope. If another scope or injected config contributes the second header, --replace-all in the local scope cannot remove it. The helper should either:

• explicitly enumerate and neutralize all effective sources for the fork operation, or
• invoke git with a one-shot config/environment that suppresses inherited auth and supplies exactly one header.

Also verify that the outer withGitHubHostToken wrapper is not combined with another auth mechanism inside pushSignedCommits.

Related

• Fork-backed create_pull_request fails with duplicate Authorization HTTP 400 #48414
• fix: wrap fork push sequences in withGitHubHostToken to prevent duplicate Authorization (HTTP 400) #48595
• Duplicate 'Authorization' header (HTTP 400) on git ops in push_to_pull_request_branch safe output #40280

[bryanchen-d]

A configuration-only workaround was tested in https://github.com/microsoft/vscode-engineering/actions/runs/30474888665:

• jobs.safe_outputs.pre-steps set GIT_CONFIG_GLOBAL to a fresh empty file before generated checkouts.
• The setting propagated through both checkouts and Process Safe Outputs.
• The first fork operation still read one effective extraheader and failed with Duplicate header: "Authorization"; counts again grew 1→2→3→4.

This rules out the normal global Git config file as the second source. The failed workaround was reverted. The remaining source is repository-local/generated checkout authentication or another mechanism inside the push path.