Windows のメインマシンと Mac の出張用ノート、それから Cloudflare の検証用に立てた Ubuntu の VM、と複数 OS をまたいで開発をしていると、ある日突然 Antigravity の Agent に小さな修正を依頼しただけなのに、diff のプレビューがファイル全体真っ赤に染まる、という現象に出くわすことがあります。コードはほぼ一文字も変わっていないのに、Git も Antigravity の Checkpoint も「全行が差し替わった」と判定します。これは多くの場合、改行コードの混在が原因です。
私自身、Dolice Labs の 4 サイト（Claude Lab / Gemini Lab / Antigravity Lab / Rork Lab）を Mac と Windows の両方で運用しているので、この問題には何度か足を取られました。最初に気づいたのは、Antigravity の Agent に MDX 記事のフロントマターを微修正させたとき、CI が「793 ファイル変更」と表示して push が拒否された瞬間でした。本当に変更したのは 1 行だけだったのに、です。
この記事は、その時に整理した診断手順と、git・エディタ・Agent の三層で再発を防ぐ実用的な手当てを残しておきます。
症状チェック — まずこれが起きていないか
改行コード混在が原因の場合、次のいずれかが観測されます。
- Antigravity の Checkpoint プレビューで、変更していないはずの行まで赤緑両方に出る
git diffがファイル全体を「変更」として表示するgit statusで変更ファイル数が直感より明らかに多い- VS Code / Antigravity のステータスバーで
CRLFとLFが混在しているファイルが見える - ESLint や Prettier が「Expected linebreaks to be 'LF' but found 'CRLF'」と警告する
特に CI で prettier --check や eslint --max-warnings 0 を走らせている場合、Agent の編集が原因で大量の warning が発生し、PR が通らなくなります。
原因を切り分ける 3 つのコマンド
まずは犯人を特定します。プロジェクトのルートで以下を順に実行してください。
# 1. リポジトリ内のファイルが何で改行されているか調査
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. Git の自動変換設定を確認
git config --get core.autocrlf
git config --get core.eol
# 3. .gitattributes が存在するか
cat .gitattributes 2>/dev/null || echo "(no .gitattributes)"core.autocrlf が true（Windows のデフォルト）で .gitattributes が無いプロジェクトは、ほぼ確実にこの問題を抱えています。Windows でチェックアウトしたファイルが CRLF に変換され、Mac / Linux で開いたときに LF に戻され、Agent の編集差分にそれが乗ってしまうからです。
対処 1 — .gitattributes でファイル単位の方針を固定する
最も効果が高いのは .gitattributes をプロジェクトに置くことです。リポジトリのルートに次の内容で作成します。
# デフォルトは LF（テキストファイル全般）
* text=auto eol=lf
# 明示的にバイナリ扱いするもの
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.webp binary
*.woff binary
*.woff2 binary
*.ttf binary
*.otf binary
*.ico binary
*.pdf binary
*.zip binary
# 明示的に LF にするもの（OS をまたいでも揺らがせない）
*.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 固有のスクリプトだけ CRLF
*.bat text eol=crlf
*.cmd text eol=crlf配置したら、リポジトリ全体に既存ファイルを再正規化します。
# 既存の全ファイルを .gitattributes に従って書き直す
git add --renormalize .
git status
git commit -m "chore: normalize line endings to LF"このコミットは「実質的な変更ゼロ・改行コードだけ揃える」という性質のものなので、できれば単独のコミットとして残しておくと、後から差分の歴史を追うときに迷いません。
対処 2 — Antigravity / VS Code 側の既定値を LF にする
Antigravity（VS Code ベース）のエディタが新しいファイルを作るときに何で改行するかを揃えます。プロジェクトの .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" }
}files.eol を "auto" のままにしておくと OS のデフォルトに引きずられるので、ここで明示的に LF を選び切ります。.bat と .cmd だけは Windows 上で動かす都合で例外的に CRLF にしておきます。
対処 3 — Agent に「改行コードを変えるな」を教える
ここまでで土台は整いますが、Antigravity の Agent そのものに方針を伝えておかないと、リファクタリング系の指示で大きなブロックを書き換えるときに、Agent が独自判断で改行コードを変えてしまうことがあります。
プロジェクトルートに AGENTS.md を置いて、次のような注意書きを入れておきます。
## ファイル編集時の注意
- このリポジトリの改行コードは **LF 固定**（`.bat`/`.cmd` のみ CRLF）。
- ファイル全体を書き直すような大規模な編集を提案する場合でも、
既存の改行コードを保ったまま編集を返すこと。
- 既存のファイルを読み込んだ際は、最後の改行を勝手に追加・削除しない。
- UTF-8 BOM をファイル先頭に挿入しない。Antigravity の Agent は AGENTS.md を読みながら作業するので、この一文があるかないかで diff の安定度がかなり変わります。私の手元では、Agent に大きめの編集を任せたあとに「変更してないはずなのに差分が出てしまった行」のノイズが目に見えて減りました。
検証 — 実際に直ったか確かめる
3 つの対処を入れたあと、次の手順で実際に直っているか検証します。
# 1. 改行コードが混在しているファイルがゼロになったか
git ls-files | while read f; do
if [ -f "$f" ] && file "$f" | grep -q "CRLF"; then
echo "残: $f"
fi
done
# 2. ダミーの小さな編集をして diff を見る
echo "" >> some-test-file.md
git diff some-test-file.md
# → 末尾 1 行だけの差分になっていれば成功
# 3. 元に戻す
git checkout some-test-file.md*.bat / *.cmd 以外で「残:」と出るファイルが残っている場合は、おそらく .gitattributes 配置前のキャッシュが残っています。git rm --cached -r . のあと再度 git add . をすると確実にクリーンになります（ただし作業ツリーは消えないので安全です）。
トラブルシューティング — 直らないときの追加確認
ここまでやっても直らない場合、次のうちどれかに該当しているはずです。
(A) Windows 側の core.autocrlf がグローバルに true のまま
git config --global core.autocrlf inputinput にすると、コミット時は LF・チェックアウト時はそのまま、という挙動になります。チームの Windows ユーザー全員にこの設定を共有することで、Windows ローカルでだけ CRLF に戻る、という事故が消えます。
(B) WSL とネイティブ Windows でリポジトリを共有している
WSL 側で git clone したリポジトリを \\wsl$\Ubuntu\... 経由で Windows 側 Antigravity から開くと、改行コード変換が二重にかかります。Antigravity から開くリポジトリは、WSL 内に置いた場合は WSL の Antigravity（Remote-WSL モード）から、Windows 側に置いた場合は Windows の Antigravity から、と一致させる方が穏やかです。
(C) 一部のファイルだけ「常に CRLF」が要件
たとえば古い C/C++ のテストスクリプトや、Windows 固有のレガシーツールが食べさせるテキストファイルが対象なら、.gitattributes で個別に eol=crlf を指定しておきます。
test/fixtures/win-only/*.txt text eol=crlf全体を振り返って
改行コード混在は、Agent の編集差分が「ノイズだらけ」になる地味で厄介な問題ですが、.gitattributes で方針を固定し、エディタの既定値を LF に揃え、AGENTS.md で Agent に方針を伝える、というシンプルな三層で大半は再発しなくなります。
次のアクションとしては、いま開いているプロジェクトのルートで git config --get core.autocrlf と cat .gitattributes を一度だけ確かめてみてください。.gitattributes が無いプロジェクトであれば、この記事のテンプレートをそのままコピーして、git add --renormalize . を 1 回走らせる、それだけで diff の景色がだいぶ静かになります。
私自身、複数 OS とリモートの両方を行き来して長く運用していると、こうした小さな環境差は必ずどこかで噛みつかれるものだと感じます。同じ場所でつまづいている方の参考になれば幸いです。