Problem
When using push_to_pull_request_branch with a long-running branch pattern (like autoloop's accumulating iteration branches), the max_patch_size check measures the patch as the total diff from the initial checkout (default branch) to the agent's final working tree — not the incremental diff from the existing PR branch head to the new commits.
This means that as a long-running branch accumulates accepted iterations and diverges further from the default branch, the patch size grows monotonically — even though each individual iteration only changes a few KB. Eventually it exceeds max_patch_size and every subsequent push fails.
Example
In githubnext/tsessebe, the autoloop build-tsb-pandas-typescript-migration program has accumulated ~8 accepted iterations on its long-running branch. The total branch divergence from main is 2567 KB. Each new iteration only adds a few KB, but the patch is always 2567+ KB because it's measured from main:
Patch size: 2567 KB (maximum allowed: 1024 KB)
##[error] Message 1 (push_to_pull_request_branch) failed: Patch size (2567 KB) exceeds maximum allowed size (1024 KB)
Expected behavior
For push_to_pull_request_branch, the patch size should be computed as the diff between the existing PR branch head and the new commits being pushed — i.e., just the incremental changes from this iteration.
The current behavior makes sense for create_pull_request (where no prior branch state exists), but for push_to_pull_request_branch the baseline should be the existing branch tip, not the default branch.
Current workaround
Setting max-patch-size to 10240 KB (the framework maximum) in the safe-outputs config. This effectively disables the safety check, which is not ideal — especially since the framework caps it at 10 MB, and a sufficiently large long-running branch could exceed even that.
Context
This affects any gh-aw workflow that uses the long-running branch + single draft PR pattern, where a branch accumulates many commits over time without being merged back to the default branch. The autoloop workflow is the primary example.
Problem
When using
push_to_pull_request_branchwith a long-running branch pattern (like autoloop's accumulating iteration branches), themax_patch_sizecheck measures the patch as the total diff from the initial checkout (default branch) to the agent's final working tree — not the incremental diff from the existing PR branch head to the new commits.This means that as a long-running branch accumulates accepted iterations and diverges further from the default branch, the patch size grows monotonically — even though each individual iteration only changes a few KB. Eventually it exceeds
max_patch_sizeand every subsequent push fails.Example
In githubnext/tsessebe, the autoloop
build-tsb-pandas-typescript-migrationprogram has accumulated ~8 accepted iterations on its long-running branch. The total branch divergence frommainis 2567 KB. Each new iteration only adds a few KB, but the patch is always 2567+ KB because it's measured frommain:Expected behavior
For
push_to_pull_request_branch, the patch size should be computed as the diff between the existing PR branch head and the new commits being pushed — i.e., just the incremental changes from this iteration.The current behavior makes sense for
create_pull_request(where no prior branch state exists), but forpush_to_pull_request_branchthe baseline should be the existing branch tip, not the default branch.Current workaround
Setting
max-patch-sizeto 10240 KB (the framework maximum) in the safe-outputs config. This effectively disables the safety check, which is not ideal — especially since the framework caps it at 10 MB, and a sufficiently large long-running branch could exceed even that.Context
This affects any gh-aw workflow that uses the long-running branch + single draft PR pattern, where a branch accumulates many commits over time without being merged back to the default branch. The autoloop workflow is the primary example.