Repository navigation
v0.83.5: fork create_pull_request still sends duplicate Authorization headers #48952
Description
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/vscodehead-repo:bryanchen-d/vscode- separate
safe-outputs.github-appandcreate-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.
Activity
bryanchen-d commentedon Jul 29, 2026
A configuration-only workaround was tested in https://github.com/microsoft/vscode-engineering/actions/runs/30474888665:
jobs.safe_outputs.pre-stepssetGIT_CONFIG_GLOBALto a fresh empty file before generated checkouts.Process Safe Outputs.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.
fix: clear all git config scopes before overriding extraheader to pre…
fix: clear all git config scopes before overriding extraheader to pre…
bryanchen-d commentedon Jul 30, 2026
A second reproduction used
--gh-aw-ref mainafter #49059 merged and still failed: https://github.com/microsoft/vscode-engineering/actions/runs/30564172951The generated shim pinned the setup action to the #49059 merge commit directly:
However,
Process Safe Outputsstill executed the old local-only override/restore behavior:Retries again accumulated
read 2,read 3, andread 4. No--global --unset-all/ all-scope cleanup commands appeared in the log.This suggests the action payload executed at the #49059 merge commit does not yet contain the rebuilt helper artifact, even though the source commit includes the fix. A release/action build that carries the regenerated runtime artifact still appears necessary before fork-backed
create_pull_requestcan be validated.