A release automation agent is creating pull requests for hotfix branches. The team notices all PRs are targeting develop as the base branch instead of release/v2.1. The agent's system prompt says 'create a PR for the hotfix.' The tool call that creates the PR accepts a base parameter. What is the most likely cause and fix?
Select an answer to reveal the explanation.
Short Explanation
When you tell an agent to create a PR without naming the base branch, it falls back to the repo default—here, develop. You fix it by putting the exact base branch in the prompt and making sure the tool call explicitly sets base to release/v2.1.
Full Explanation
GitHub's REST API for creating pull requests requires a base parameter specifying the target branch. When this parameter is omitted or left null, the API defaults to the repository's configured default branch — in this case, develop. The agent's system prompt ('create a PR for the hotfix') provides no base branch specification, so the model either omits the base parameter or provides a generic value.
The two-layer fix is: update the agent's system prompt to include explicit base branch instructions (e.g., 'create a PR targeting release/v2.1 as the base branch'), and ensure the tool call's base parameter is populated from the agent's context or a configured default for hotfix workflows.
The token-permission explanation is incorrect. Protected branches can be used as PR base branches by any user with repository access — branch protection governs who can push directly to or merge into a branch, not who can target it as a PR base.
The wrong-MCP-server explanation would manifest as PRs appearing in the wrong repository entirely, not as PRs in the correct repository with the wrong base branch.
The branch-protection explanation is not how GitHub branch protection works. Branch protection rules apply to pushes and merges, not to designating a branch as a PR target.
Explicit base branch specification in both prompt and tool parameters is the reliable fix.