Claude Code「Error writing file」の対処法：Ctrl+O で原因を特定

Claude Code の会話画面に出る Write(パス) ⎿ Error writing file は、失敗したことだけを伝える短いラベルです。原因はこの一行には書かれていません。Ctrl+O でトランスクリプト表示を開き、失敗した Write の結果に出ている英語のメッセージを読むと、どこを直すべきかが決まります。直す場所はおおむね 3 つに分かれます。権限・パス・文字コード・macOS の設定といった環境、読み直しや小分けといった Claude の書き方、そしてファイル自体は書けている既知のバグです。

一度だけ赤字が出て、Claude が自分で直して次に進んだなら対応は不要です。同じエラーが 2〜3 回続く、あるいは Claude が Bash や python でファイルを書こうとし始めたら、手を止めてメッセージを確認してください。

以下の実測結果は、2026年10月16日に Claude Code 2.1.295（Claude デスクトップ版、macOS、モデルは Opus 5.5）で Write ツールの 7 つのケースと Edit ツールの 2 つのケースを試したものです。Windows、出力トークン切れ、相対パスや plan モードのバグは再現していないため、GitHub の報告と公式ドキュメントに基づいて書いています。同日時点の npm 上の最新版は 2.1.301 です。

Error writing file の正体：Ctrl+O で本当のメッセージを見る

会話画面には、たとえば次のように表示されます（GitHub issue #29841 の報告より）。

● Write(app/Mcp/Tools/GetMyTasksTool.php)
  ⎿ Error writing file

この一行の裏で、Claude にはツールの実行結果として詳しいメッセージが返っています。Claude Code 公式ドキュメントのエラー一覧には、ファイル編集がブロックされたとき会話画面には短い Error editing file だけが出て、全文は Ctrl+O で開くトランスクリプト表示に出る、と書かれています。GitHub に報告された Write の失敗も、会話画面では同じように一行だけの表示です。

確認の手順は次のとおりです。

1. ターミナルで Claude Code を開いたまま Ctrl+O を押します。interactive mode のドキュメントでは、これは transcript viewer の切り替えで、ツールの使用と実行の詳細が表示されます。
2. 赤字になった Write(…) または Update(…) の呼び出しを探し、その下の結果を読みます。EACCES、File has been modified since read のような英文が原因の手がかりです。
3. q、Esc、Ctrl+C のどれかで会話画面に戻ります。

ショートカットはターミナルや OS によって変わることがあると、公式ドキュメントにも注記があります。デスクトップ版では、ツール呼び出しの結果欄にメッセージの本文がそのまま表示されました（2.1.295 で確認）。

公式のエラー一覧には Error writing file という文字列の項目がありません。そのため、検索や公式ドキュメントで調べるときは、トランスクリプト表示で読んだ詳しいメッセージのほうを手がかりにします。エラー一覧の Tool errors の節は「Claude はツールのエラーの多くを自分で修正する」という説明で始まっています。一度の赤字で慌てなくてよいのはこのためです。

メッセージ別の早見表：原因と最初の一手

トランスクリプト表示で読んだメッセージの冒頭を、左の列と照らし合わせてください。

File has been modified since read：エディタや整形の変更

Claude がファイルを読んだ後、書き込む前に別の何かがそのファイルを変更した、という意味です。実測では、Read のあとに Bash でファイルの中身を書き換えてから Write させると、次のメッセージで止まりました。

File has been modified since read, either by the user or by a linter. Read it again before attempting to write it.

この確認は、あなたやほかのツールが加えた変更を Claude が気付かずに上書きしないためのものです。変更の出どころとして報告されているのは次のようなものです。

• エディタでの保存や自動保存。IDE でファイルを開いたりプレビューしたりしただけで、中身は変わらないのに更新日時が変わって失敗したという macOS の報告もあります（GitHub issue #10498、2.0.x 系の時期）。
• フォーマッタやリンター。保存時の自動整形や、編集後に走る PostToolUse フックの整形がファイルを書き換えます。
• Windows や WSL、Unity エディタで、File has been unexpectedly modified が繰り返し出るループ（GitHub issue #11463）。別のプロセスがファイルをロックしている場合にも、この紛らわしいメッセージになるという報告があります（GitHub issue #10245）。

直し方は、まず Claude に「このファイルを読み直してから書いて」と伝えることです。メッセージ自体がそう指示しているので、多くは Claude が自分で読み直します。それでも繰り返すなら、変更の出どころを止めます。そのファイルをエディタで閉じる、自動保存をいったん切る、フォーマッタが同じファイルを書き換え続けていないか確かめる、といった対応です。フックで整形している場合の設定は「Claude CodeのHooks・Skills・スラッシュコマンドを使い分ける：呼び出し方と設定例」で扱っています。

Edit ツールについては、v2.1.208 以降、ディスク上で変わったファイルでも old_string が現在の内容と完全に一致すれば編集が通るようになりました（tools reference の Edit の説明）。v2.1.208 より前のバージョンで Edit がこのエラーを繰り返すなら、更新するだけで減る可能性があります。

EACCES と EPERM：フォルダ権限と macOS のプライバシー保護

EACCES: permission denied はフォルダの権限を見る

実測では、権限を 555（読み取りと実行のみ）にしたフォルダの中に Write させると、次のエラーになりました。

EACCES: permission denied, open '.../rodir/new.txt.tmp.35734.7a96eba60d51'

注目したいのはパスの末尾です。対象は new.txt なのに、エラーが指しているのは new.txt.tmp.（プロセス番号）.（16 進数） という一時ファイルです。Write はまず同じフォルダに一時ファイルを書き、それを本来の名前にリネームしているとみられます。そのため、効いてくるのはファイルではなくフォルダの書き込み権限です。

確認と修正は次のとおりです。

ls -ld 保存先のフォルダ      # 所有者と権限を確認する
chmod u+w 保存先のフォルダ   # 所有者が自分なら書き込み権限を戻す

所有者が自分以外（sudo で作ったフォルダなど）の場合は、所有者を戻すか、自分が書き込める場所で作業させます。

chmod 444 ではファイルを守れない

逆の結果も出ました。書き込み可能なフォルダの中で、ファイルだけを chmod 444（読み取り専用）にしても、Write はそのファイルを上書きできました。上書き後も権限は -r--r--r-- のままで、中身だけが新しくなっていました。一時ファイルとリネームという書き方からすると、筋の通る結果です。

特定のファイルを Claude に書き換えさせたくないなら、ファイルの権限ではなく、Claude Code の権限設定で Read や Edit の deny ルールを使うか、フォルダごと読み取り専用にします。Read の deny ルールに該当するパスへの Write は、新規作成も含めて次のメッセージで拒否されます（Write に効くのは v2.1.228 以降）。

File is covered by a Read deny rule in your permission settings and cannot be written.

このメッセージが出たのに書き込ませたい場合は、/permissions か settings でそのルールを外すか、範囲を狭めます。許可モードと deny ルールの関係は「Claude Code --dangerously-skip-permissionsの使い方：確認が残る理由と安全な選び方」を参照してください。

macOS のデスクトップ・書類・ダウンロードで出る EPERM

macOS で ~/Desktop、~/Documents、~/Downloads、iCloud Drive の中で EPERM: operation not permitted が出る場合、公式のエラー一覧によると、たいていは macOS がターミナルアプリからそのフォルダへのアクセスを止めています。この説明は作業ディレクトリを読む場面についてのものですが、同じ OS の制限は書き込みにもかかります。

対処は、ターミナルアプリを Cmd+Q で終了して開き直すことです。それでも同じフォルダで ls が失敗するなら、システム設定 > プライバシーとセキュリティ > ファイルとフォルダでターミナルアプリにそのフォルダを許可し、ターミナルを開き直します。プロジェクトをホームディレクトリ直下の別フォルダに置けば、この制限自体を避けられます。

ENOSPC と EDQUOT：一時ディレクトリの容量

ENOSPC はディスクの空き不足、EDQUOT は自分に割り当てられたクォータの上限を意味します。公式のエラー一覧では、Claude Code の一時ディレクトリがあるファイルシステムについて、不要なファイルを消すか、CLAUDE_CODE_TMPDIR で余裕のある場所を指定して Claude Code を起動し直すよう案内しています。クォータはディスクに空きがあっても満杯になることがあります。

Shift-JIS で File is not valid UTF-8：文字コードを保つ

Shift-JIS で保存された CSV や古いソースコードを Edit しようとすると、次のメッセージで拒否されます（公式エラー一覧の File is not valid UTF-8）。

File is not valid UTF-8. It may use a legacy encoding such as Windows-1252, Shift-JIS or GBK, or be binary. This tool saves the whole file as UTF-8, which would replace every byte it cannot decode with U+FFFD. Nothing was written. ...

Edit はファイル全体を UTF-8 で保存し直すため、読めないバイトをすべて置換文字 U+FFFD に変えてしまいます。それを避けるために変更を拒否し、ファイルには触れません。UTF-8 のつもりのファイルでも、不正なバイト列が一つあれば同じメッセージになります。なお v2.1.296 より前の Edit は拒否せずに編集を適用し、読めないバイトを U+FFFD に変えて保存していました。古いバージョンを使っているなら更新してください。

気を付けたいのは Write のほうです。tools reference の非 UTF-8 ファイルの説明によると、Write はこうしたファイルでも丸ごと置き換えられます（新しい内容に U+FFFD が含まれる場合を除く）。そしてUTF-8 で保存するので、元の文字コードは失われます。Shift-JIS 前提で読み込むシステムに渡すファイルなら、エラーが出なくても問題になります。

どちらにするかは、ファイルを Shift-JIS のまま残す必要があるかで決めます。

Shift-JIS のまま残す場合は、Claude に「文字コードを保ったままシェルコマンドで変更して」と伝えます。エラーメッセージ自体もこの方法を指示しています。Python なら次のように読み書きします。macOS の Python 3.12 では、改行が CRLF の Shift-JIS の CSV が、文字コードも改行も変わらずに書き換わりました。

python3 -c "
p = 'sales.csv'
t = open(p, encoding='cp932', newline='').read()
t = t.replace('1200', '1500')
open(p, 'w', encoding='cp932', newline='').write(t)
"

UTF-8 に変換してよい場合は、先に変換してしまえば以後は Edit が普通に使えます。

file -I sales.csv                                     # macOS。Shift-JIS は charset=unknown-8bit と出る
iconv -f SHIFT_JIS -t UTF-8 sales.csv > sales-utf8.csv

変換後のファイルを Shift-JIS 前提のツールで開くと文字化けするので、使い道を確かめてから変換してください。

InputValidationError：大きなファイルは小分けに書く

長いファイルを一度に書かせたときや、長いセッション、サブエージェントの中で、次のようなメッセージとともに Write が失敗し、Claude が同じ失敗を何度も繰り返すことがあります（GitHub issue #895、2026年10月16日時点で未解決）。

InputValidationError: Write failed due to the following issue: The required parameter `content` is missing

file_path が欠けているという形もあります。どちらもツールに渡すはずの引数が届いていない状態で、報告では Claude の返答が途中で切れたことが原因とされています。直前に API Error: Claude's response exceeded the 32000 output token maximum… が出て、続けて Error writing file になった例も報告されています（GitHub issue #7927、古いバージョン）。

公式のエラー一覧によると、出力上限に達したときのメッセージは次の 2 種類です。

• API Error: Claude's response exceeded the ... output token maximum. To configure this behavior, set the CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable.
• … for a request sent without streaming. The CLAUDE_CODE_MAX_OUTPUT_TOKENS environment variable cannot raise this limit.

後者は、ストリーミングの要求が失敗して非ストリーミングで送り直された場合で、返答は 64,000 トークンまでに制限され、環境変数でも引き上げられません。v2.1.299 より前は、送り直した返答がここで切れてもメッセージが出ず、完了したように見えていました。

効果が広く報告されている対処は、一度に書かせる量を減らすことです。

1. まず 100 行前後の骨組みだけを Write で作らせます。
2. 残りは Edit で 100〜200 行ずつ足していきます。
3. 毎回指示するのが面倒なら、CLAUDE.md に「大きなファイルは分割して書く」と書いておきます。

公式のエラー一覧も、上限に収めるために「1 回の返答で 1 つのファイルか 1 つのセクション」のように小分けで頼むことを勧めています。返答の途中で切れたなら、continue と返せば続きを書かせられます。

ゲートウェイやサードパーティのモデルを通している場合は、この失敗が起きやすいという報告があります。issue #895 では、LiteLLM などの OpenAI 互換プロキシ経由でストリーミングが失敗すると非ストリーミングに切り替わり、そちらの低い出力上限でツール呼び出しの JSON が途中で切れる、という利用者の分析が共有されています。GLM 4.5 から 4.7 に変えたら、すべてのツール呼び出しの引数が空になったという書き込みもあります。どちらも Anthropic が確認したものではありません。Anthropic の API に直接つないだときに再発しないなら、原因は経路のほうです。設定の見直しは「Claude Code API 設定：キー、settings.json、モデル、ゲートウェイの確認手順」と「Claude CodeでOpenRouterとDeepSeekを使う：経路、設定、初回エラー対応」が参考になります。

パスが原因：フォルダ指定、シンボリックリンク、worktree

実測では、フォルダを指すパスに Write させると次のメッセージになりました。

.../isdir is a directory, not a file. To create a file inside it, include the file name in file_path.

ファイル名まで含めたパスを指定し直させれば解決します。一方で、存在しない親フォルダは自動で作られました（newparent/sub/file.txt への Write が成功）。「フォルダがないから書けない」ということは、少なくとも 2.1.295 では起きません。

公式のエラー一覧には、パスの形に関するメッセージがほかにもあります。

• Refusing to write …: it is a symbolic link. Write to the link's target path instead：シンボリックリンクそのものには書きません。リンク先の実パスで書かせます。
• This write was blocked because the path is spelled in a form that cannot be safely resolved…：worktree に隔離されたセッション（v2.1.217 以降）で、シンボリックリンク経由などで行き先を確定できないパスを止めたものです。会話画面には Error editing file とだけ出ます。通常は Claude がメッセージに示された直接のパスで自動的にやり直します。同じファイルで繰り返すなら、docs/current -> ../README.md のような .. を含むリンクを経由していないか確認し、実ファイルのパスで編集させます。
• This write was blocked because the path is network-shaped…：UNC 共有（\\server\share\file）や /net の自動マウントのパスです。ローカルのパスで指定し直させます。

読んでいないファイルの上書き：Opus 4.6 以前は Read が必須

既存のファイルを Write で上書きする前に Read が必要かどうかは、モデルとバージョンで変わります（tools reference の Write の説明）。

v2.1.228 より前は、どのモデルでも Read が必要でした。cat、head、tail、sed -n、grep、rg などで 1 つのファイルを（パイプやリダイレクトなしで）表示した場合も、読んだものとして扱われます。

実測では、Opus 5.5 で一度も読んでいない既存ファイルへの Write は成功しました。limit=3 で先頭の 3 行だけ読んだ大きなファイルへの Write も成功しており、行数を指定した読み込みは PARTIAL view の扱いにはなりませんでした。古いモデルや古いバージョンで、読んでいないファイルへの Write が失敗しているなら、「先にこのファイルを Read して」と頼めば通ります。

書けているのに Error writing file：既知のバグと Windows

GitHub には、Error writing file そのものが不具合として出る報告がいくつかあります。前の 2 つはファイル自体は書けている表示上の問題、後の 2 つは Windows で実際に書き込みが失敗する問題です。いずれも修正の記録がないまま閉じられており、修正されたかどうかは公開情報からは分かりません。

• 相対パスでの誤表示（GitHub issue #29841、v2.1.63、macOS）：app/Mcp/Tools/… のような相対パスで書くと、ファイルは正しく作られるのに、すべての Write に赤い Error writing file が出ます。
• plan モードの最初の書き込み（GitHub issue #24151、v2.1.37〜2.1.50）：plan ファイルを書くたびに 1 回目が Error writing file になり、自動の再試行で成功します。WSL2、macOS、Ubuntu、Manjaro で報告され、最後に正常だったのは 2.1.29 とされています。
• Windows の Git Bash で特殊文字（GitHub issue #63838、Windows 10）：内容にシングルクォート、バックスラッシュ、</ を含むと Write や Edit が失敗し、Claude が python -c やヒアドキュメントで書く方法に切り替えます。
• Windows の MINGW64 で cygpath（GitHub issue #25971）：Command failed: cygpath -u '…' ですべての Write が失敗します。報告では一時フォルダのパスが HIPOLI~1 のような 8.3 形式の短い名前になっていました。

詳しいメッセージが見当たらず、ファイルを開くと期待どおりの内容で保存されているなら、前の 2 つに当たります。この場合は無視してかまいません。Claude には「ファイルはもう保存されているので次へ進んで」と伝えれば、無駄な再試行を止められます。再発を避けるには、Claude Code を claude update（デスクトップ版はアプリの更新）で最新にし、相対パスで繰り返すなら絶対パスで書くよう頼みます。Windows の 2 つは実際に書き込めていません。Claude が python などで書き直した結果が正しければ実害はありませんが、毎回起きるなら更新してから再確認してください。

Error editing file と String to replace not found

既存ファイルの一部を書き換える Edit（会話画面では Update(パス)）が失敗すると、Error editing file と表示されます。こちらもトランスクリプト表示で原文を確認します。Edit が通るための条件は tools reference の Edit の説明にまとまっています。

• 一致：置き換え前の文字列 old_string がファイル内に書かれたとおりに存在すること。正規表現やあいまい一致は使われず、空白やインデントが 1 文字違うだけで外れます。2.1.295 の実測では、ファイルにない文字列を指定すると String to replace not found in file. になりました。
• 一意：old_string がちょうど 1 回だけ現れること。2 回現れる文字列を指定すると、実測では Found 2 matches of the string to replace, but replace_all is false. になりました。複数あるときは、前後を含めた長い文字列で場所を特定するか、replace_all: true で全部置き換えます。
• 読み込み：Write と同じく、古いモデルでは事前の Read が必要です。
• 権限と文字コード：Read の deny ルール（Edit には v2.1.208 以降で適用）と、前述の UTF-8 以外のファイルの拒否は Edit にもかかります。

対処の基本は、Claude にファイルを読み直させてから、前後の行を含めて置き換え範囲を指定させることです。同じ Update が何度も失敗し、間に Read が挟まらない場合は、作業を止めて「いまのファイルを読んでから直して」と指示します。

再試行を止める目安と、保存できたかの確かめ方

Claude はエラーを受け取ると自分で直そうとしますが、次の場面ではあなたが止めたほうが早く済みます。

• 同じメッセージが 2〜3 回続く：原因が環境側（権限、macOS の設定、deny ルール、文字コード）にあるなら、Claude が何度試しても結果は変わりません。
• ファイルはもう書けている：誤表示のバグです。中身を確かめて先へ進ませます。
• InputValidationError や出力上限のメッセージが繰り返される：同じ大きさで書き直しても同じところで切れます。小分けに切り替えさせ、ゲートウェイ経由なら経路を疑います。
• Claude が Bash や python で書き始めた：Shift-JIS のファイルなら正しい選択です。それ以外では、Write の「読んだ後に変更されていないか」の確認を通らずに書くことになるため、エディタで開いているファイルの変更を上書きしていないか確かめてください。

保存できたかどうかは、Claude の報告ではなくファイルそのもので確かめます。

git status --short          # どのファイルが変わったか
git diff -- 対象のファイル    # 期待どおりの差分か
file -I 対象のファイル        # 文字コード（Linux では file -i）
ls -ld 保存先のフォルダ       # 権限と所有者

Claude Code 自体が終了してしまい、書き込みエラーの前にプロセスが落ちている場合は別の問題です。「Claude Code process exited with code 1 の直し方: 再インストール前に分岐で切り分ける」で切り分けてください。

Claude Code の書き込みエラーに関する質問

--dangerously-skip-permissions で書き込みエラーは消えますか？

消えません。このオプションが省くのは Claude Code の許可確認であり、フォルダの権限（EACCES）、macOS のプライバシー保護（EPERM）、文字コード、出力切れといった原因は残ります。Read の deny ルールやフックも引き続き効きます。詳しくは「Claude Code --dangerously-skip-permissionsの使い方：確認が残る理由と安全な選び方」を参照してください。

Windows で Claude Code の Error writing file が続く原因は？

報告されているのは、Git Bash 環境でシングルクォートやバックスラッシュ、</ を含む内容を書くと失敗するケースと、一時フォルダの短い 8.3 形式のパスで cygpath が失敗するケースです。ほかに、エディタや Unity が同じファイルを開いていて File has been unexpectedly modified が繰り返し出る報告もあります。まずトランスクリプト表示でどれに当たるかを確かめ、Claude Code を最新にしてから再確認してください。

Error writing file が出たファイルは壊れていますか？

多くの場合は壊れていません。公式ドキュメントによると、Read の deny ルールはファイルに触れる前に呼び出しを拒否し、File is not valid UTF-8 で拒否された Edit も何も書き込みません。フォルダの権限エラーの実測でも、エラーが指していたのは本体ではなく一時ファイルでした。注意が必要なのは、失敗ではなく成功したほうです。Shift-JIS のファイルを Write が上書きすると、エラーは出ずに UTF-8 に変わります。git diff と file -I で中身と文字コードを確かめてください。