Claude Code で一日中コードを書いていると、ある時間帯から突然 File has been modified since read it. You need to re-read the file before you can edit it. というエラーが連発し始めることがあります。さっきまで普通に編集できていたのに、Edit ツールが立て続けに失敗して、Claude が同じファイルを何度も Read し直して、トークンとレートリミットだけが消費されていく状況です。
私の場合、Dropbox 経由で共有しているプロジェクトと、Prettier を formatOnSave で有効にしているフロントエンドリポジトリの2つで、特にこのエラーが多く出ていました。原因が分からないままだと「Claude Code 側のバグかも」と疑いたくなりますが、整理してみると引き金になっているのは大抵3つの設定だけです。順番に潰していくと、ほとんどの環境でこのエラーは出なくなります。
エラーが言っていること自体はシンプル
Claude Code は Edit / Write ツールを呼ぶ前に「直前に Read したときのファイルの mtime（最終更新時刻）」を覚えています。Edit のタイミングで実ファイルの mtime が更新されていると、「ディスク上のファイルがあなたが見ていたものと違う」と判定して、書き換えを止めます。
つまりこのエラーは Claude Code が壊れているのではなく、Read と Edit の間に第三者がファイルを書き換えた事実を、安全装置として正しく検出している状態です。直すべき対象は Claude Code ではなく、その「第三者」を黙らせる側の設定になります。
第三者の正体は、私の観測範囲ではほぼ次の3つに収束します。
- 保存時に走るフォーマッタ（Prettier / Black / gofmt / Biome 等）
- クラウド同期のファイル書き戻し（Dropbox / iCloud Drive / Google Drive）
- 別ターミナルで動いている他のプロセス（テストランナー、watch コマンド、別の Claude Code セッション）
ケース1: フォーマッタがファイルを上書きしている
圧倒的に多い原因がこれです。VS Code の editor.formatOnSave が true になっていると、Claude Code が Write したファイルを保存した瞬間に Prettier や Biome が再フォーマットして書き戻し、mtime が更新されます。次の Edit がエラーで止まる、というループに入ります。
私は Claude Code 専用のワークスペースだけ formatOnSave を切る運用に変えました。.vscode/settings.json をプロジェクト直下に置いておくと、エディタを開くたびにそのプロジェクトだけ無効化できます。
{
"editor.formatOnSave": false,
"editor.formatOnPaste": false,
"editor.formatOnType": false,
"files.autoSave": "off"
}files.autoSave も "afterDelay" や "onFocusChange" になっていると、ユーザーが何もしなくても定期的にファイルが書き戻されてしまうため、Claude Code を回している間は "off" にしておくのが安全です。
フォーマッタ自体を捨てたくない場合は、Claude Code 側の Hooks で PostToolUse 時にだけフォーマッタを走らせる構成にすると競合がなくなります。書き込みが終わった直後の決まったタイミングだけ整形できるので、いつ書き換わるかが予測可能になります。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATHS\" 2>/dev/null || true"
}
]
}
]
}
}この設定にしてから、私の環境ではフロントエンドプロジェクトでの File modified エラーが体感で9割以上減りました。
ケース2: クラウド同期がバックグラウンドで書き戻している
私はメイン環境を Dropbox 配下の作業フォルダで運用しているのですが、Dropbox や iCloud Drive、Google Drive のようなクラウド同期サービスは、別マシンの変更を取り込むタイミングでファイルを書き戻します。このとき mtime が更新されるので、Claude Code が同じファイルを編集中だと当然エラーになります。
特に厄介なのが、自分が複数 Mac で同じプロジェクトを開きっぱなしにしているケースです。サブ機の Finder がフォルダを開いているだけで .DS_Store が頻繁に更新され、それに連動してフォルダ自体の mtime も動きます。
対処として、私は次の3段階で運用を変えました。
第一に、Claude Code を回している間はクラウド同期を一時停止します。Dropbox なら通知領域から「同期を一時停止」、iCloud ならネットワーク接続を切るのが手っ取り早い手段です。
第二に、ヘビーに自動化する作業は同期フォルダの外で実行します。私は git リポジトリを ~/repos/ 配下に clone し直して、そこで Claude Code を回す運用にしました。Dropbox 配下に置くのは「成果物の最終バックアップ」だけにしています。
第三に、.gitignore と並べて .DS_Store や *.swp などの副次ファイルが生成されないように .metadata_never_index を置いたり、Spotlight のインデックス対象から外したりして、Read 自体に巻き込まれる頻度を減らしました。
ケース3: 他のプロセスが裏で書き込んでいる
Next.js の next dev、Vite の vite、Jest の --watch、TypeScript の tsc --watch、ESLint の --fix --watch などの watch 系プロセスは、依存ファイルを書き換えることがあります。next dev は .next/types/ 配下に型ファイルを定期生成しますし、tsc --watch --emit 構成だとソースを変えるたびに dist/ 配下が更新されます。
Claude Code がそれらの「生成物」を Read していると、watch プロセスの再生成が走るたびに File modified エラーになります。
私が取った対処は次の3つです。
ひとつ目は、Claude Code セッション中は watch 系を全部止めることです。dev サーバーを起動した状態でコード生成を頼むのではなく、生成 → 確認 → dev サーバー再起動の順に分けます。地味ですが、これだけでエラーがほぼ消える環境もあります。
ふたつ目は、生成物ディレクトリを Claude Code が触らないようにすることです。プロジェクト直下に CLAUDE.md を置き、.next/、dist/、build/、coverage/ などを「触らないでほしいフォルダ」として明示しておきます。Claude Code はこのファイルを読んで挙動を寄せてくれます。
# Project Notes for Claude Code
## Do not read or edit these directories
- `.next/` — Next.js が生成。watch で常時書き換わる
- `dist/`, `build/` — ビルド成果物。直接編集禁止
- `coverage/` — Jest のレポート出力
- `node_modules/` — 依存パッケージ。手で触らない
## When you need to run the dev server
1. ユーザーに dev サーバー起動を依頼する（自分では起動しない）
2. 起動中は Edit を避ける。やむを得ない場合はユーザーに dev を一旦止めてもらうみっつ目は、同時に複数の Claude Code セッションを同じリポジトリで動かさないことです。git worktree を切って別ディレクトリにすれば共存できるので、並行作業をしたい場合は worktree 運用に寄せるのが結局一番安全でした。
エラーが出たときの即時対処
設定を整えても、たまにはエラーが出ます。その場で確実に進めたいときは、次の順で対処すると最短で復帰できます。
最初にやるのは、Claude にもう一度同じファイルを Read してもらうことです。「ファイルが更新されているので、もう一度 Read してから編集してください」と一言伝えれば、Claude Code は最新の mtime でファイルを取得し直してから Edit を試みます。
次に、同じファイルで連続して同じエラーが出る場合は、何が書き戻しているのかをユーザー側で特定します。私は macOS なら fs_usage -w -f filesys /path/to/file を別ターミナルで走らせて、誰が write しているかを直接観察します。Linux なら inotifywait -m /path/to/file が同じ役割を果たします。原因プロセスが分かれば、あとはそのプロセスを止めるだけです。
最後の手段として、エラーが出ているファイルだけを別ディレクトリにコピーして、そこで Claude Code に作業させて、終わったら戻すという回避策もあります。整形ルールや同期からは完全に切り離せるので、長時間の集中作業を止めずに済みます。
長く付き合うほど設計の問題に変わる
このエラーは最初は「Claude Code の小さな癖」に見えますが、長く使うほど、自分の開発環境がツール同士の競合を許容する作りになっているかどうかを問うてくる存在に変わっていきます。
私は2014年から個人開発でiPhone / Androidアプリを作り続けてきて、累計5,000万ダウンロードを超える壁紙アプリの運用を支えてきました。ここ数年で AI コーディングエージェントが本格的に開発フローに入ってきてからは、自動保存・自動整形・クラウド同期といった「人間ひとりの開発なら便利だった機能」が、AI エージェントが回るとそのまま競合源になることを実感しています。
formatOnSave を切ること、watch を切ること、Dropbox 配下で AI を走らせないこと。一つひとつは小さな判断ですが、積み上げると「AI エージェントが安心して動ける環境」になります。File has been modified since read のエラーは、その境界線を可視化してくれる便利なシグナルだと、最近は前向きに受け止めています。
同じ課題に向き合っている方の参考になれば嬉しいです。