BUG: generate_git_patch reports an unauthenticated promisor blob-fetch failure as "Branch 'X' does not exist locally"

[sg650]

Summary

create_pull_request regressed between v0.85.4 and v0.86.1/0.86.2. generate_git_patch Strategy 1 now performs a network branch-existence check after it has already computed the merge-base and enumerated the commits on that branch. In a workflow whose checkout uses persist-credentials: false (gh-aw's own default) that call fails authentication, the failure is reported as "Branch 'X' does not exist locally", and patch generation aborts — so the agent commits a working change and then cannot open a PR.

On a blobless (--filter=blob:none) working copy the same call also surfaces as fatal: could not fetch <sha> from promisor remote.

A/B evidence

Same repository, same workflow source, same inputs, same custom git fetch --filter=blob:none step, 26 minutes apart. The only variable is the gh-aw version.

v0.85.4 — success. Strategy 1 completes 8 ms after enumerating commits; no network access:

[generate_git_patch] Strategy 1: Using pinned SHA <sha> (branch: agent-fix/example)
[generate_git_patch] Strategy 1 (full): Computing merge-base with main (ignoring any stale origin/agent-fix/example)
[generate_git_patch] Strategy 1 (full): origin/main exists locally
[generate_git_patch] Strategy 1 (full): Computed merge-base: <sha>
[generate_git_patch] Strategy 1: Resolved baseRef <sha> to SHA <sha>
[generate_git_patch] Strategy 1: Found 1 commits between <sha> and <sha>
[generate_git_patch] Strategy 1: SUCCESS - Generated patch with 111 lines
[generate_git_patch] Final: SUCCESS - patchSize=4750 bytes, patchLines=111

v0.86.2 — failure. Identical trace, then a ~670 ms network round trip that fails auth:

[generate_git_patch] Strategy 1: Using pinned SHA <sha> (branch: agent-fix/example)
[generate_git_patch] Strategy 1 (full): Computing merge-base with main (ignoring any stale origin/agent-fix/example)
[generate_git_patch] Strategy 1 (full): origin/main exists locally
[generate_git_patch] Strategy 1 (full): Computed merge-base: <sha>
[generate_git_patch] Strategy 1: Resolved baseRef <sha> to SHA <sha>
[generate_git_patch] Strategy 1: Found 2 commits between <sha> and <sha>
[generate_git_patch] Strategy 1: Branch 'agent-fix/example' does not exist locally - ERR_SYSTEM: remote: Invalid username or token. Password authentication is not supported for Git operations.

The error handed back to the agent:

Pinned SHA <sha> failed to generate patch: ERR_SYSTEM: remote: Invalid username or token.
Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/<org>/<repo>.git/'
fatal: could not fetch <sha> from promisor remote

Reproduced twice within the same run (the agent retried), and the branch did exist locally — the commits were made in that working copy and the same trace had just enumerated them.

Why this is a bug, not configuration

1. The branch is local. Strategy 1 has already resolved the merge-base and counted the commits on that branch in that working copy. A network call to decide whether it "exists locally" is a contradiction.
2. No credentials are available by design. Every gh-aw-emitted actions/checkout uses persist-credentials: false. "Configure Git credentials" runs later in the job and does not cover this call site, so any git operation reaching the remote here is guaranteed to fail auth.
3. The failure is misclassified. An ERR_SYSTEM auth error is reported as "does not exist locally", which points anyone debugging it in the wrong direction, and it aborts the strategy instead of falling back.
4. Blobless clones compound it. With --filter=blob:none the same call additionally needs promisor hydration (could not fetch <sha> from promisor remote) — so even with credentials, patch generation is reaching for objects it should be reading locally.

Impact

Any agentic workflow using the create-pull-request safe output on v0.86.1+ can investigate, edit, validate, and commit — and then silently cannot deliver. No PR appears, and the only trace is the misleading "does not exist locally" line in the MCP gateway log.

Expected

Strategy 1 should determine branch existence from local refs only (e.g. git rev-parse --verify --quiet refs/heads/<branch>) and generate the patch from local objects, with no remote access. If a remote call is genuinely required, it must (a) use the job's credentials and (b) report an auth failure as an auth failure, then fall back rather than abort.

Environment

• gh-aw v0.86.2 (failing) vs v0.85.4 (working); also reproduced on v0.86.1
• engine: copilot, strict security, Linux runner
• checkout: gh-aw defaults (persist-credentials: false, fetch-depth: 1), plus a workflow step that runs git fetch --filter=blob:none --tags --unshallow origin
• create-pull-request safe output with preserve-branch-name: true

[sg650]

Reproduced again on v0.86.2 with an unrelated agent change, identical signature — so this is not specific to the branch or the diff:

[generate_git_patch] Strategy 1: Found 2 commits between <sha> and <sha>
[generate_git_patch] Strategy 1: Branch '<local-branch>' does not exist locally - ERR_SYSTEM: remote: Invalid username or token. Password authentication is not supported for Git operations.

The agent retried per its own policy and got the same result both times, then fell back to report_incomplete. The rest of the run was green: the change was committed to the local branch, specs passed, and a validated decision record was persisted. The only thing that could not happen was the PR.

Three occurrences now — twice on v0.86.1, once on v0.86.2 — against zero on v0.85.4 in the same repository and workflow.

[sg650]

Correction — my original diagnosis was wrong. This is not a v0.86 regression, and the A/B in the issue body was confounded. Narrowing the report to the one defect that is real: the error message.

What actually happens

The object that fails to fetch is a blob, not a ref. In my case I could identify it exactly:

<sha> = .github/aw/actions-lock.json  at  <merge-base>
<merge-base> = git merge-base origin/main HEAD

The chain:

1. The checkout is fetch-depth: 1, so only the checkout commit's blobs are local.
2. A step in my own workflow runs git fetch --filter=blob:none --tags --unshallow origin to get the commit graph cheaply. That leaves origin configured as a promisor remote (remote.origin.promisor=true, remote.origin.partialclonefilter=blob:none) — permanently, in .git/config.
3. generate_git_patch bases the patch on merge-base(main, <agent-branch>).
4. Diffing base→head needs the base-side blobs of every changed file.
5. Those blobs are absent, so git lazily fetches them from the promisor remote. The credential my fetch step used was git -c http.<url>.extraheader=…, i.e. per-command and never persisted, and the gh-aw checkout is persist-credentials: false. So the lazy fetch is unauthenticated and fails.

Why my A/B looked like a version regression: the passing run was dispatched from the default branch, where merge-base == the checkout commit, so every base-side blob is already present and nothing hydrates. The failing runs were dispatched from a feature branch 13 commits diverged from the default branch, so the base was an older commit whose blobs were never fetched. Base-branch divergence was the real variable; the gh-aw version happened to co-vary with it. Apologies for the noise.

So items 1 and 2 in my original "why this is a bug" list are withdrawn — the remote access is git's own lazy hydration on a partial clone, and credentials being absent is the repository owner's problem to solve, not gh-aw's.

The part that is still a bug

Point 3 stands, and it is what made this take a day to understand:

[generate_git_patch] Strategy 1: Branch '<branch>' does not exist locally - ERR_SYSTEM: remote: Invalid username or token. Password authentication is not supported for Git operations.

An authentication failure while hydrating a missing blob is reported as "Branch does not exist locally". The branch did exist locally — the same trace had just resolved its merge-base and enumerated its commits two lines earlier. Anyone reading that line goes looking at refs, branch naming, and preserve-branch-name, none of which are involved.

Suggested fix, small and self-contained:

• Distinguish the two failures. git rev-parse --verify --quiet refs/heads/<branch> answers "does this branch exist locally" with no network and no ambiguity; only report that message when it actually fails.
• When a git invocation fails with an auth or promisor error, surface it as such. A hint like "the repository is a partial clone (remote.origin.promisor=true) and the lazy blob fetch is unauthenticated" would have made this self-diagnosing, since gh-aw already knows it emitted persist-credentials: false.

Happy for this to be retitled/rescoped as a diagnostics issue, or closed if you'd rather not carry it — but the current message actively misdirects on partial clones, which are an increasingly common way to keep agentic checkouts cheap.