Coding Agent Repository Controls

Maintainers using coding agents should add a queue or check that replays merges between open agent-authored pull requests before review. The check can run git merge-tree across co-active PR pairs, post a conflict summary, and block low-priority agent PRs that touch the same source files until the first PR lands or closes.

The operational pain is visible in GitHub data. In AIDev-pop, exact temporal overlap appeared in 40.2% of repositories with agent-authored PRs and covered 79.4% of agent PRs. Merge replay found textual conflicts in 19.8% of same-agent pairs and 41.7% of cross-agent pairs, with most conflicted files in source code. A first test is simple: run the check for two weeks on repositories where agents open multiple PRs, then compare conflict comments, CI reruns, and maintainer rebase work against the prior two weeks.

Teams running coding agents on issues, pull requests, and CI output should treat every external text field as untrusted data with a separate typed envelope for trusted metadata. A practical build is a tool-response adapter that passes author, resource ID, tool name, and execution history through parser-owned fields, while comments, logs, web text, and model-visible excerpts remain quoted data. The same adapter should reject or escape JSON-like delimiters, fake tags, spoofed tool-output blocks, and copied UI identifiers inside untrusted fields.

This belongs in the agent runtime, not only in prompt rules. The agent data injection paper shows attackers can place delimiters, JSON-like structure, tags, or spoofed metadata inside untrusted content so the model reads it as trusted agent data. The reported attacks include spoofed GitHub issue comments and fake tool responses for coding agents, with remote code execution and supply-chain paths shown on Claude Code, Codex, and Gemini CLI. A cheap validation pass is to replay the paper’s delimiter and metadata-spoofing cases against the team’s own GitHub issue reader and PR review tools, then fail the build if untrusted text can alter trusted fields.

Engineering teams choosing a coding agent should run candidate agents inside rebuildable repository sandboxes with real tests, hidden judge checks, and progress logs across multi-hour work. The evaluation should record whether the agent searched the right files, localized the fault, produced a patch, verified it, recovered after failure, and gave an honest status when it stalled. This can start with five to ten internal bugs that already have known fixes and test cases.

Several new results point to the same evaluation shape. KAT-Coder-V2.5 reports AutoBuilder raising executable environment construction success from 16.5% to 57.2% and filtering trajectories by exploration, localization, patch quality, verification, recovery, and honesty. EdgeBench measures agents over 12-hour executable tasks and finds that early progress can predict later performance with high fit. EvoAgentBench adds a transfer check by linking tasks through reusable procedures for search, debugging, and verification, while current automatic memory methods still show negative-transfer cases. A useful internal scorecard should include environment rebuild success, pass/fail outcome, time-to-first-valid-test, recovery after failed patches, and whether any stored procedure helped or hurt a later task.