Why Antigravity Agent Edits Fail With 'patch does not apply' and How to Fix It

You ask the Antigravity agent to fix a function, it reasons through the change just fine, and then the edit dies on a single line: patch does not apply or hunk #2 FAILED. The logic the agent produced is correct, but the final write to disk misses. This started happening to me regularly once I began running several agents in parallel across my apps.

Here is the conclusion first: in almost every case, the code the agent wants to write is not wrong. The problem is that the file changed between the moment the agent read it and the moment it tried to apply the diff. This is a timing and state issue, not a code issue. Miss that distinction and you will rewrite the prompt forever without fixing anything.

Read which hunk actually failed

A patch does not apply error comes from git apply (or an equivalent patcher) being unable to match the diff's context lines against the real file. The agent anchors its diff on a few lines around the edit. If even one character of those anchor lines differs in the actual file, the match fails.

The first thing to check is the hunk number in the error. If you see hunk #1 succeeded but hunk #2 FAILED, the front of the file applied and the back drifted. That tells you the whole file is not stale — something touched one specific region — which narrows the cause immediately.

Why an unappliable patch appears in the first place

In my setup the causes fell into three buckets.

The first is a conflict with format-on-save. Prettier, ESLint --fix, or your editor's format-on-save rewrites indentation or quotes right after the agent read the file, so the anchor lines no longer match. The classic case: the agent built its diff assuming 'single' quotes, but the save hook converted them to "double".

The second is concurrent edits from multiple agents. I keep several wallpaper and wellness apps running, and I would occasionally point two sub-agents at the same utility file. If one rewrites the file and the other then applies a diff built against the older version, it fails by definition.

The third is mismatched line endings. In a repo where CRLF and LF are mixed, the agent may build its diff assuming LF while the file is CRLF, so every line reads as "changed" and the whole patch dies. This creeps in silently when you develop across Windows and macOS.

Fix 1: make the agent re-read the latest state

The fastest fix is to have the agent read the target again before editing. Name the failed file explicitly and ask again.

Before editing src/utils/format.ts, read the whole file again,
then rebuild the diff against the current contents.
The previous diff was based on a stale snapshot and failed to apply.

This realigns the anchor lines with the file as it is now, and it usually applies. The state was simply out of sync, so no rethinking of the code is needed.

Fix 2: pin the order between formatter and agent edits

To stop recurrence, keep the save hook from cutting in on the agent's edit. I write the formatter policy into AGENTS.md so the agent's output matches the existing style from the start.

# AGENTS.md (excerpt)
 
## Code style
- Formatter is Prettier; follow .prettierrc.
- Single quotes, semicolons on, two-space indentation.
- Before building a diff, check the file's current style and match it.

Pinning the formatter config in the repo also keeps the agent's output and the post-save state identical, which avoids anchor drift.

// .prettierrc
{
  "singleQuote": true,
  "semi": true,
  "tabWidth": 2
}

Fix 3: normalize line endings at the repo level

The line-ending wipeout disappears at the root once you normalize with .gitattributes. Drop this at the repo root to force LF for text files.

# .gitattributes
* text=auto eol=lf

If CRLF is already mixed in, renormalize the whole tree once after adding the setting.

git add --renormalize .
git commit -m "Normalize line endings to LF"

Now the LF the agent assumes and the real file agree, and the "every line changed" verdict from a newline mismatch stops happening.

A small practice to keep parallel edits from colliding

When you run multiple agents, splitting ownership by file is the most reliable guard. Running the four Dolice Labs sites and several apps at once, one simple rule — never let two agents touch the same file simultaneously — removed most of my apply failures. If they must touch the same area, serialize: let one edit finish and commit before the next starts. Failures you can prevent structurally are steadier to remove through workflow than through prompt tweaks.

I hope this shortens the diagnosis for anyone losing time to the same symptom.