safe-outputs: base_branch derived from target repo HEAD causes extract-base-branch to checkout wrong branch

[tore-unumed]

Problem

The safe-outputs MCP server determines the base branch by running git rev-parse --abbrev-ref HEAD in the target repository checkout. When the agent has already switched to a feature branch (e.g. git checkout -b feature/FOO-123), this returns the feature branch instead of the repo's default branch.

This causes two distinct failures:

Symptom 1: extract-base-branch checks out wrong branch

The platform's extract-base-branch step uses base_branch from agent_output.json to checkout the workflow repository. When base_branch is set to the target repo's feature branch, the checkout fails because that branch does not exist in the workflow repo.

Symptom 2: Patch generation includes entire repo history (higher impact)

When branch == baseBranch (both are the feature branch), the patch generation strategies fail in sequence:

1. Strategy 1: Tries origin/feature/FOO-123 — does not exist (new branch). Falls through.
2. Strategy 2: Checks GITHUB_SHA — belongs to a different repo (multi-repo checkout). Falls through.
3. Strategy 3 (fallback): Picks a random remote ref, computes merge-base against an ancient commit, and runs git format-patch <ancient-commit>..feature/FOO-123 — producing a patch containing the entire repository history.

The resulting patch has hundreds of files (every file ever touched in the repo's history), which triggers E003: Cannot create pull request with more than N files. The agent's actual changes (e.g. 8 files, +41/-42 lines) are correct, but the inflated patch causes rejection.

The fallback (creating an issue instead) may also fail if issues are disabled on the target repo, resulting in complete silent failure with no PR and no issue.

Reproduction

1. Configure a multi-repo workflow where repos are cloned under repos/<name>/
2. The agent creates a feature branch in a target repo: git checkout -b feature/FOO-123
3. Agent commits changes and calls create_pull_request with branch: "feature/FOO-123" and no explicit base
4. MCP server runs git rev-parse --abbrev-ref HEAD → gets feature/FOO-123
5. Both branch and baseBranch are feature/FOO-123
6. Symptom 1: base_branch output is feature/FOO-123, causing workflow repo checkout failure
7. Symptom 2: Patch generation falls through all strategies, lands on Strategy 3 with a bad merge-base, produces multi-MB patch with hundreds of historical commits

Server log evidence (Symptom 2 — patch generation)

[generate_git_patch] Strategy 1: Checking if branch 'feature/FOO-123' exists locally
[generate_git_patch] Strategy 1: Branch 'feature/FOO-123' exists locally
[generate_git_patch] Strategy 1 (full): Computing merge-base with feature/FOO-123
[generate_git_patch] Strategy 1 (full): origin/feature/FOO-123 not found locally, attempting fetch
[generate_git_patch] Strategy 1 (full): Fetch failed - fatal: couldn't find remote ref feature/FOO-123
[generate_git_patch] Strategy 1 (full): No remote refs available, falling through to Strategy 2
[generate_git_patch] Strategy 2: GITHUB_SHA not found in repo (cross-repo checkout?)
[generate_git_patch] Strategy 3: Cross-repo fallback - finding commits not reachable from remote refs
[generate_git_patch] Strategy 3: Found merge-base <ancient-commit> with ref refs/remotes/origin/<old-branch>
[generate_git_patch] Strategy 3: SUCCESS - Generated patch with 122231 lines
[generate_git_patch] Final: SUCCESS - patchSize=5730494 bytes, patchLines=122231

The patch contained 400 commits (the entire repo history), 210 unique files, and was 5.7 MB — for an actual change of 8 files.

Expected behavior

When base is not provided by the agent, the tool should resolve the repository's default branch (e.g. via git symbolic-ref refs/remotes/origin/HEAD) instead of using git rev-parse --abbrev-ref HEAD. This would:

1. Set baseBranch correctly for patch generation (merge-base would find the right common ancestor)
2. Set base_branch output correctly for the platform's checkout step
3. Make both symptoms impossible

Current workaround

For Symptom 1 only: we patch the generated extract-base-branch step post-compile to validate the branch exists locally before using it. This does not fix Symptom 2.

For Symptom 2: no workaround exists. The agent's PR is silently lost. The only recovery is to re-run the workflow.

Environment

• gh-aw CLI: v0.74.4
• Engine version: 1.0.48

[tore-unumed]

Update: base parameter does not fix patch generation

We confirmed that passing base explicitly does not fix the generate_git_patch inflation.

Evidence from run 26172307512

The agent correctly passed base: "master" for all create_pull_request calls. Verified from ingestion logs:

[INGESTION] Processing line 1: {"base":"master","body":"## Summary\n\nFixes service invoice...
[INGESTION] Processing line 2: {"base":"master","body":"## Summary\n\nRe-enables...

Results:

• testing repo: patch = 1,472 bytes, 35 lines → correct ✅
• migration repo: patch = 5,725,100 bytes, 122,149 lines → inflated ❌

Both PRs passed base: "master". The testing PR succeeded (PR created with 1 file). The migration PR was rejected by max_patch_files: 100 (210 files).

Root cause refinement

The generate_git_patch function ignores or mishandles the base parameter for repos cloned under multi-repo workflows (repos cloned via git clone into subdirectories, not checked out at the workflow root via actions/checkout).

The testing repo produces a correct 35-line patch while the migration repo produces a 122k-line patch from the same run, same agent, same base: "master" parameter. The difference is likely in how the patch generator resolves origin/master in the cloned repo context.

Impact

This means there is no instruction-level workaround for multi-repo workflows. The platforms generate_git_patchfunction must correctly use thebase` parameter when generating diffs for cloned repos.