push_to_pull_request_branch: allowed-files policy validates branch history, not the agent patch #67074

Observed behavior

On a PR branch that already contains an author commit touching a file type outside the allowed-files list (in our case a .pyc under __pycache__/), a push_to_pull_request_branch call from the agent is rejected with an allowed-files policy error, even though the agent commit itself touches only an allowed file (a .json). The agent cannot recover: the offending commit predates its work, force-push and amend are unavailable to it, so the auto-fix path dies and falls back to posting a comment.

Expected behavior

The allowed-files / protected-files policy should validate the file set the agent contributes (its patch, or the commits it adds on top of the pre-existing branch head), never the branch delta against an earlier base. A pre-existing author commit should not block a push the agent is responsible for.

Mechanism (v0.88.8, github/gh-aw-actions setup @ 5e508589)

In setup/js/push_to_pull_request_branch.cjs:

• The bundle pre-apply check computes the file set via git diff --name-only <rangeBaseRef>..<bundleRef> (getBundlePreApplyFiles, ~line 119, called at ~line 1112), and the post-apply verification re-diffs <rangeBaseRef>..HEAD (~line 1275).
• rangeBaseRef starts as the branch remote ref but is re-anchored to the recorded base_commit when the patch carries one (~lines 989-1017).
• When that recorded base predates the branch tip (for example a merge-base with the default branch captured at patch-generation time), pre-existing author commits fall inside the validated range and their files trip checkFileProtectionPostApply, producing POLICY_FILE_PROTECTION_DENIED_REASON_CODE.

In our run the rejection surfaced to the agent as an immediate tool-call error at emit time (two logged attempts: first "repo required for wildcard target", then the allowed-files rejection), which suggests the same policy is also enforced in the gateway/MCP layer before the push job runs; if so, the same scoping fix is needed there as well.

Suggested fix

Scope the allowed-files / protected-files evaluation for push_to_pull_request_branch (and symmetrically for create_pull_request when the branch pre-exists) to the agent contribution: the patch file set, or <remoteHeadBeforePatch>..HEAD after apply (that variable already exists, ~lines 974-985) — never a base that predates the branch head the agent started from.

Repro

1. A PR branch with a pre-existing author commit touching a non-allowed file type (for example tools/**/__pycache__/*.pyc, with allowed-files: ["**/*.go", "**/*.yml", "**/*.yaml", "**/*.json", "**/*.md"]).
2. An agentic workflow with push-to-pull-request-branch where the agent commits a fix touching only an allowed file and emits the push item.
3. The push is rejected, citing the author-owned file.