# Claude Code「Error writing file」の対処法：Ctrl+O で原因を特定 > Claude Code の Error writing file は要約です。Ctrl+O で原文を読めば、権限・文字コード・外部の変更・出力切れ・誤表示のどれか判別できます。 - URL: https://blog.laozhang.ai/ja/posts/claude-code-error-writing-file - Published: 2026-10-16 - Updated: 2026-10-16 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about) - Topic: Claude Code - Tags: Claude Code, Error writing file, Error editing file, トラブルシューティング, 文字コード --- 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 の報告](https://github.com/anthropics/claude-code/issues/29841)より）。 ```text ● Write(app/Mcp/Tools/GetMyTasksTool.php) ⎿ Error writing file ``` この一行の裏で、Claude にはツールの実行結果として詳しいメッセージが返っています。[Claude Code 公式ドキュメントのエラー一覧](https://code.claude.com/docs/en/errors#write-or-command-blocked-because-the-path-cannot-be-safely-resolved)には、ファイル編集がブロックされたとき会話画面には短い `Error editing file` だけが出て、全文は `Ctrl+O` で開くトランスクリプト表示に出る、と書かれています。GitHub に報告された Write の失敗も、会話画面では同じように一行だけの表示です。 確認の手順は次のとおりです。 1. ターミナルで Claude Code を開いたまま `Ctrl+O` を押します。[interactive mode のドキュメント](https://code.claude.com/docs/en/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, either by the user or by a linter.` | 読んだ後にエディタ、フォーマッタ、hooks などがファイルを変えた | 読み直させてから書かせる。変更の出どころを止める | | `EACCES: permission denied, open '…/new.txt.tmp.…'` | 保存先のフォルダに書き込み権限がない | フォルダの所有者と権限を確認する | | `EPERM: operation not permitted`（macOS のデスクトップ、書類など） | macOS がターミナルアプリのアクセスを止めている | システム設定でフォルダへのアクセスを許可する | | `File is not valid UTF-8.` | Shift-JIS などレガシーな文字コードのファイル | 文字コードを保つシェルコマンドで書くか、UTF-8 に変換する | | `… is a directory, not a file.` | パスがフォルダを指している | ファイル名まで含めたパスを指定させる | | `File is covered by a Read deny rule …` | 権限設定の `Read` deny ルール | ルールを外すか範囲を狭める | | `InputValidationError: Write failed …` や `API Error: Claude's response exceeded the … output token maximum` | 出力が途中で切れ、ファイルの中身が届いていない | 骨組みを書いてから小分けに追記させる | | `Refusing to write …: it is a symbolic link.` や `This write was blocked because the path …` | シンボリックリンク、worktree の保護、ネットワークパス | リンク先の実パスで書かせる | | `ENOSPC` / `EDQUOT` | 一時ディレクトリのあるディスクの容量やクォータ不足 | 空き容量を作るか `CLAUDE_CODE_TMPDIR` を変える | | 詳しいメッセージがなく、ファイルは保存されている | 既知の表示バグ（相対パス、plan モード） | 中身を確かめ、問題なければ先へ進ませる | | `Command failed: cygpath -u '…'`、または Windows の Git Bash で特殊文字を含む内容だけ失敗 | Windows で報告されているバグ | 最新版に更新し、Claude が別の方法で書いた結果を確かめる | ## `File has been modified since read`：エディタや整形の変更 Claude がファイルを読んだ後、書き込む前に別の何かがそのファイルを変更した、という意味です。実測では、Read のあとに Bash でファイルの中身を書き換えてから Write させると、次のメッセージで止まりました。 ```text 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](https://github.com/anthropics/claude-code/issues/10498)、2.0.x 系の時期）。 - フォーマッタやリンター。保存時の自動整形や、編集後に走る `PostToolUse` フックの整形がファイルを書き換えます。 - Windows や WSL、Unity エディタで、`File has been unexpectedly modified` が繰り返し出るループ（[GitHub issue #11463](https://github.com/anthropics/claude-code/issues/11463)）。別のプロセスがファイルをロックしている場合にも、この紛らわしいメッセージになるという報告があります（[GitHub issue #10245](https://github.com/anthropics/claude-code/issues/10245)）。 直し方は、まず Claude に「このファイルを読み直してから書いて」と伝えることです。メッセージ自体がそう指示しているので、多くは Claude が自分で読み直します。それでも繰り返すなら、変更の出どころを止めます。そのファイルをエディタで閉じる、自動保存をいったん切る、フォーマッタが同じファイルを書き換え続けていないか確かめる、といった対応です。フックで整形している場合の設定は「[Claude CodeのHooks・Skills・スラッシュコマンドを使い分ける：呼び出し方と設定例](https://blog.laozhang.ai/ja/posts/claude-code-hooks-slash-commands-skills)」で扱っています。 Edit ツールについては、v2.1.208 以降、ディスク上で変わったファイルでも `old_string` が現在の内容と完全に一致すれば編集が通るようになりました（[tools reference の Edit の説明](https://code.claude.com/docs/en/tools-reference#edit-tool-behavior)）。v2.1.208 より前のバージョンで Edit がこのエラーを繰り返すなら、更新するだけで減る可能性があります。 ## `EACCES` と `EPERM`：フォルダ権限と macOS のプライバシー保護 ### `EACCES: permission denied` はフォルダの権限を見る 実測では、権限を `555`（読み取りと実行のみ）にしたフォルダの中に Write させると、次のエラーになりました。 ```text EACCES: permission denied, open '.../rodir/new.txt.tmp.35734.7a96eba60d51' ``` 注目したいのはパスの末尾です。対象は `new.txt` なのに、エラーが指しているのは `new.txt.tmp.（プロセス番号）.（16 進数）` という一時ファイルです。Write はまず同じフォルダに一時ファイルを書き、それを本来の名前にリネームしているとみられます。そのため、効いてくるのは**ファイルではなくフォルダの書き込み権限**です。 ![Write は同じフォルダに一時ファイルを書いてからリネームするため、フォルダ 555 では EACCES になり、ファイルだけ 444 では上書きされる](https://blog.laozhang.ai/posts/ja/claude-code-error-writing-file/img/write-temp-file-rename.webp) 確認と修正は次のとおりです。 ```bash 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 以降）。 ```text File is covered by a Read deny rule in your permission settings and cannot be written. ``` このメッセージが出たのに書き込ませたい場合は、`/permissions` か settings でそのルールを外すか、範囲を狭めます。許可モードと deny ルールの関係は「[Claude Code --dangerously-skip-permissionsの使い方：確認が残る理由と安全な選び方](https://blog.laozhang.ai/ja/posts/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](https://code.claude.com/docs/en/errors#file-is-not-valid-utf-8)）。 ```text 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 ファイルの説明](https://code.claude.com/docs/en/tools-reference#non-utf-8-files)によると、Write はこうしたファイルでも丸ごと置き換えられます（新しい内容に `U+FFFD` が含まれる場合を除く）。そして**UTF-8 で保存するので、元の文字コードは失われます**。Shift-JIS 前提で読み込むシステムに渡すファイルなら、エラーが出なくても問題になります。 どちらにするかは、ファイルを Shift-JIS のまま残す必要があるかで決めます。 ![Shift-JIS のファイルは Edit が拒否して残り、Write は UTF-8 で上書きする。Shift-JIS のまま残すか UTF-8 に変換するかで直し方を選ぶ](https://blog.laozhang.ai/posts/ja/claude-code-error-writing-file/img/shift-jis-edit-vs-write.webp) **Shift-JIS のまま残す場合**は、Claude に「文字コードを保ったままシェルコマンドで変更して」と伝えます。エラーメッセージ自体もこの方法を指示しています。Python なら次のように読み書きします。macOS の Python 3.12 では、改行が CRLF の Shift-JIS の CSV が、文字コードも改行も変わらずに書き換わりました。 ```bash 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 が普通に使えます。 ```bash 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](https://github.com/anthropics/claude-code/issues/895)、2026年10月16日時点で未解決）。 ```text 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](https://github.com/anthropics/claude-code/issues/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、モデル、ゲートウェイの確認手順](https://blog.laozhang.ai/ja/posts/claude-code-api-configuration)」と「[Claude CodeでOpenRouterとDeepSeekを使う：経路、設定、初回エラー対応](https://blog.laozhang.ai/ja/posts/claude-code-openrouter-deepseek)」が参考になります。 ## パスが原因：フォルダ指定、シンボリックリンク、worktree 実測では、フォルダを指すパスに Write させると次のメッセージになりました。 ```text .../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 の説明](https://code.claude.com/docs/en/tools-reference#write-tool-behavior)）。 | 条件 | 上書き前の Read | | --- | --- | | Claude Opus 4.6、Claude Haiku 4.5 とそれ以前のモデル | 常に必要。読んでいない既存ファイルへの Write はエラーになる | | それより新しいモデル（v2.1.228 以降） | 読むのに許可確認が要らず、Read ツールが使えるなら不要 | | Jupyter ノートブック、`PARTIAL view` の通知付きで一部だけ読んだファイル | すべてのモデルで必要 | | 新規ファイル | 不要 | 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](https://github.com/anthropics/claude-code/issues/29841)、v2.1.63、macOS）：`app/Mcp/Tools/…` のような相対パスで書くと、ファイルは正しく作られるのに、すべての Write に赤い `Error writing file` が出ます。 - **plan モードの最初の書き込み**（[GitHub issue #24151](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/63838)、Windows 10）：内容にシングルクォート、バックスラッシュ、`