create_pull_request 100-file limit counts full branch diff, not per-push diff

[mrjf]

Problem

The create_pull_request safe-outputs handler enforces a hardcoded 100-file limit, but it appears to count files based on the full branch-vs-main diff rather than the files in the patch the agent actually generated for this push.

This breaks autoloop programs that accumulate many iterations on a long-running branch. Even though:

• The branch is fully merged into main (0 commits ahead)
• The agent merges main into the branch before committing (fast-forward)
• The single iteration only touches 1-3 files

...the handler still reports hundreds or thousands of files:

E003: Cannot create pull request with more than 100 files (received 1768)
E003: Cannot create pull request with more than 100 files (received 101)

Evidence

Three autoloop programs on githubnext/tsessebe are stuck in a failure loop because of this:

Program	Branch ahead/behind main	Files in patch	Expected
perf-comparison	0 ahead, 196 behind	1768	~2 (one benchmark pair per iteration)
build-tsb-pandas-typescript-migration	0 ahead, 75 behind	101	~3 (one feature port per iteration)
tsb-perf-evolve	0 ahead, 33 behind	n/a (hits patch size limit instead)	~1 (single file modification)

All three branches are fully merged (0 commits ahead of main). The agent correctly merges main before committing:

git checkout -B autoloop/{name} origin/autoloop/{name}
git fetch origin main && git merge origin/main --no-edit   # fast-forwards
git commit -m "[Autoloop: {name}] Iteration N: ..."

The resulting patch should contain only the files from the new commit, but the handler appears to be counting from the old (pre-merge) branch point.

Expected behavior

The file count check should apply to the files in the generated patch (i.e., what the agent is actually pushing in this iteration), not the full branch-vs-main diff. It's expected and fine for a long-running autoloop PR to accumulate hundreds of files over time — the safety concern is about a single push touching too many files.

Workaround

We've raised max-patch-size to 10240 KB (the framework max) via top-level safe-outputs config, which unblocks the byte-size failures but doesn't help with the 100-file limit since there's no max-files config option.

Affected runs

• https://github.com/githubnext/tsessebe/actions/runs/24933142674 (perf-comparison, 1768 files)
• https://github.com/githubnext/tsessebe/actions/runs/24931293995 (build-tsb, 101 files)
• https://github.com/githubnext/tsessebe/actions/runs/24932091850 (tsb-perf-evolve, patch size)

[mrjf]

Update: patch includes entire repo tree, not just the diff

Further investigation shows the patch generator is including nearly the entire repo, not just the branch-vs-main diff.

The tsessebe repo has 1775 total files. The patch for perf-comparison reported 1768 files. The agent correctly started from origin/main (git checkout -B autoloop/perf-comparison origin/main) and only committed ~10 new files (5 benchmark pairs). The patch should contain ~10 files, not 1768.

Similarly, build-tsb-pandas-typescript-migration showed 101 files in the patch for a single iteration that added ~3 files.

This suggests the create_pull_request MCP tool is generating a full-tree patch (or close to it) rather than a git diff main..HEAD style diff.

[pethers]

Can the limit be increased, configured ? 100 why is this set, any reason ?

[mrjf]

Can the limit be increased, configured ? 100 why is this set, any reason ?

I think this was just a rough heuristic to prevent runaway agents from doing to much, and it could certainly be configurable. I believe the main problem is that the file size calculation was incorrect, diffing from main to PR branch instead of from patch to PR branch, preventing large PRs from being iterated on even in small bits.

edit: copilot agreed with you and made it a setting :) #28472