Git merge conflict markers left in a file by an AI agent break the build

Any AI coding tool Last checked 2026-10-30

What you saw

A build or test run fails with a syntax error pointing at a line that reads <<<<<<< HEAD, =======, or >>>>>>> branch-name in a file the agent just touched.

The file looks like the agent picked a side of the conflict and wrote real code around it, but the three marker lines are still sitting in the file untouched.

git status shows the file as modified, not as unmerged, because the agent (or you) already ran git add on it — so git no longer flags it as a conflict needing resolution.

The failure only shows up in CI or on a teammate's machine, because the agent's own sandbox never re-ran the build after making the edit, or ran a check that does not parse that file.

What it actually means

Git drops literal marker text into a file when a merge or rebase can't auto-resolve a conflict: <<<<<<< HEAD, then your side, =======, then their side, then >>>>>>> branch-name. Resolving a conflict means deleting all three marker lines and keeping only the correct code — it is a text edit, not something git finishes for you.

An agent asked to "resolve the conflicts" or "fix the merge" can correctly pick which side's logic to keep while still leaving the marker lines in place, because picking the right code and removing the scaffolding around it are two separate steps and agents sometimes do only the first.

Once you git add the file, git considers the conflict resolved from version control's point of view — it has no idea the content is still broken. Nothing downstream checks for marker syntax unless your build happens to choke on it, which only coding/compiled languages reliably do.

In interpreted or loosely-parsed files (YAML, Markdown, JSON with a non-strict parser, plain config), the markers can sit silently for a long time without anyone noticing, because nothing immediately errors.

The fix

1. Confirm it's actually a leftover marker and not a real syntax error: search the failing file for the marker strings directly.

   grep -n '^<<<<<<<\|^=======$\|^>>>>>>>' path/to/file

2. Open the file at that line and read both sides of the conflict that are still printed between the markers — decide (or re-confirm the agent's choice of) which lines are correct.

3. Delete all three marker lines and anything from the side you are discarding. Keep only the final, correct code — there should be zero marker syntax left anywhere in the file.

4. Re-run the build or the specific check that failed before you trust the fix, not just a quick read-through — marker text is easy to half-see and miss a second occurrence further down the same file.

   grep -rn '^<<<<<<<\|^=======$\|^>>>>>>>' . --include='*.*'

5. Stage and commit the real fix with a message that says what it is, e.g. fix: remove leftover merge conflict markers in <file> — don't fold it silently into the agent's original commit if that commit already landed.

How to stop it happening again

Never tell an agent to just "resolve the conflict" and move on without asking it to show you a diff of the final file, or running the build yourself, before you accept the result.

Add a cheap pre-commit or CI grep step that fails the build if any file contains a line starting with <<<<<<<, ======= on its own, or >>>>>>> — this catches leftover markers in any file type, including ones your compiler wouldn't flag.

If an agent is doing the merge, ask it explicitly to confirm, as a separate step, that it searched the changed files for conflict marker strings after editing and found none — don't rely on it volunteering that check.

Prefer git mergetool or a rebase with --autostash plus manual conflict review for anything non-trivial; reserve agent-driven conflict resolution for conflicts you can read end to end yourself before accepting.

Related questions

Why didn't git warn me the conflict wasn't really resolved?

Git only tracks whether a path is marked resolved (via git add), not whether the file's content is syntactically or logically correct. Once you stage it, git's job is done — correctness is on you or whatever ran the staging.

Can this happen in files git doesn't treat as code?

Yes. YAML, JSON, Markdown and plain text files can hold leftover marker lines indefinitely with no build error at all, because nothing parses them strictly. These are the easiest to miss and the longest-lived.

Is a pre-commit hook enough to catch this every time?

A grep-based hook catches markers in any already-tracked file you run it against, but only if it actually runs before every commit and covers every file type you care about — scope it broadly rather than limiting it to source-code extensions.