When Antigravity Agent Edits Break Diffs Due to Mixed CRLF/LF Line Endings

If you move between a primary Windows machine, a Mac laptop for travel, and an Ubuntu VM you spun up to verify a Cloudflare deploy, sooner or later you will run into this: you ask the Antigravity Agent for a small edit, and the preview diff lights up the entire file in red. The code itself has barely changed by a single character, yet both Git and Antigravity's Checkpoint claim every line has been replaced. The culprit, more often than not, is a mix of CRLF and LF line endings.

I ran into this firsthand while running the four Dolice Labs sites (Claude Lab, Gemini Lab, Antigravity Lab, Rork Lab) from both my Mac and my Windows desktop. The clearest case showed up when I asked the Antigravity Agent to tweak a single line of MDX frontmatter, and CI rejected the push with a "793 files changed" report. The actual change was one line.

What follows is the diagnosis and a three-layer fix across git, the editor, and the Agent itself — the same notes I wrote down for myself after the incident.

Are You Seeing This?

When mixed line endings are the cause, you will usually notice one or more of these:

• Antigravity Checkpoint preview shows untouched lines as both red and green
• git diff reports the entire file as changed
• git status shows far more modified files than feels right
• VS Code / Antigravity's status bar shows CRLF and LF on files in the same project
• ESLint or Prettier warns "Expected linebreaks to be 'LF' but found 'CRLF'"

When CI runs prettier --check or eslint --max-warnings 0, an Agent edit can produce a flood of warnings and block the PR entirely.

Three Commands to Isolate the Cause

Start by identifying the culprits. Run these from the project root:

# 1. Which tracked files use CRLF?
git ls-files | while read f; do
  if [ -f "$f" ]; then
    if file "$f" | grep -q "CRLF"; then
      echo "CRLF: $f"
    fi
  fi
done | head -50
 
# 2. Check Git's automatic conversion settings
git config --get core.autocrlf
git config --get core.eol
 
# 3. Does a .gitattributes file exist?
cat .gitattributes 2>/dev/null || echo "(no .gitattributes)"

If core.autocrlf is true (the Windows default) and .gitattributes is missing, this project almost certainly has the issue. Files checked out on Windows get converted to CRLF, get rewritten as LF on Mac/Linux, and the Agent's edits inherit that drift.

Fix 1 — Pin Behavior per File Type via .gitattributes

The highest-impact step is to add a .gitattributes at the repo root with the following:

# Default to LF for text files
* text=auto eol=lf
 
# Mark these as binary explicitly
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.webp binary
*.woff binary
*.woff2 binary
*.ttf binary
*.otf binary
*.ico binary
*.pdf binary
*.zip binary
 
# Force LF for these (stable across all operating systems)
*.js text eol=lf
*.ts text eol=lf
*.tsx text eol=lf
*.jsx text eol=lf
*.mdx text eol=lf
*.md text eol=lf
*.json text eol=lf
*.yml text eol=lf
*.yaml text eol=lf
*.sh text eol=lf
 
# Windows-specific scripts: CRLF
*.bat text eol=crlf
*.cmd text eol=crlf

Once placed, renormalize all existing tracked files to follow the new rules:

# Rewrite all files according to .gitattributes
git add --renormalize .
git status
git commit -m "chore: normalize line endings to LF"

This commit is "no semantic change, line endings only" — keep it as a standalone commit so future history-spelunking is less confusing.

Fix 2 — Set the Antigravity / VS Code Default to LF

Make sure new files created in the editor also use LF. Add this to your project's .vscode/settings.json:

{
  "files.eol": "\n",
  "files.encoding": "utf8",
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true,
  "[bat]": { "files.eol": "\r\n" },
  "[cmd]": { "files.eol": "\r\n" }
}

If files.eol is left at "auto", the OS default takes over again. Pin LF explicitly here. The .bat and .cmd overrides keep CRLF only where Windows actually needs it.

Fix 3 — Tell the Agent Not to Change Line Endings

With the foundation set, the last gap is the Agent itself. When you ask Antigravity to rewrite a large block, the Agent can decide on its own to "normalize" line endings, which silently introduces drift.

Add an AGENTS.md at the project root with something like:

## File Editing Notes
 
- This repo uses **LF line endings** for everything except `.bat`/`.cmd`.
- Even when proposing a full-file rewrite, preserve the existing line
  endings of the file you are editing.
- When reading an existing file, do not add or remove the trailing newline.
- Do not insert a UTF-8 BOM at the beginning of a file.

The Antigravity Agent reads AGENTS.md while working, and having this one block visibly cuts the noise in diffs after larger edits. In my own setup, "lines that show up as changed but weren't actually touched" dropped sharply after adding it.

Verifying the Fix

After all three layers are in place, verify with the following:

# 1. Are there any CRLF files left?
git ls-files | while read f; do
  if [ -f "$f" ] && file "$f" | grep -q "CRLF"; then
    echo "still CRLF: $f"
  fi
done
 
# 2. Make a small dummy edit and inspect the diff
echo "" >> some-test-file.md
git diff some-test-file.md
# → should report only a one-line trailing diff
 
# 3. Roll it back
git checkout some-test-file.md

If files outside *.bat/*.cmd still appear under "still CRLF:", you probably have cached index entries from before .gitattributes was added. A git rm --cached -r . followed by git add . clears the index cleanly (your working tree is safe).

When It Still Won't Settle

If the symptoms persist, one of the following is usually at fault:

(A) core.autocrlf is still true globally on Windows

git config --global core.autocrlf input

input means "convert to LF on commit, leave alone on checkout." Share this setting with every Windows teammate to eliminate "fine for everyone except one machine" incidents.

(B) You're sharing the repo across WSL and native Windows

If you git clone inside WSL and then open the repo from Windows Antigravity via \\wsl$\Ubuntu\..., line-ending conversion stacks twice. Decide where the repo lives — if it's in WSL, open it from the WSL Antigravity (Remote-WSL); if it's on Windows, open it from the Windows Antigravity. Don't crisscross.

(C) Some files genuinely need to stay CRLF

For legacy C/C++ test fixtures or scripts that feed Windows-only tools, opt those paths out individually:

test/fixtures/win-only/*.txt text eol=crlf

Closing

Mixed line endings are a quiet, slightly tedious problem that drowns Agent diffs in noise. Three small layers — pin file-level behavior in .gitattributes, default the editor to LF, and tell the Agent to leave line endings alone — clear most of it for good.

For your next step, open the project you are working in right now and run git config --get core.autocrlf and cat .gitattributes once. If there is no .gitattributes, copy the template above, run git add --renormalize . once, and your diffs will go much quieter from then on.

When you run several setups across Windows, Mac, and Linux for any length of time, these small environmental seams inevitably catch you somewhere. If this helps you skip a few of those, I'd be glad to hear it.