「Transcript writes are failing」の対処 — Claude Code
入力欄の下に出るTranscript writes are failing警告の原因と直し方を解説します。原因はエラーコードで名指しされるため、対処は機械的に決まります。
このTipsでできること
作業中の入力欄の下にTranscript writes are failingという警告が常設で出ることがあります。セッション自体は止まらず作業も続けられますが、放置すると後で--resumeしたときに直近のやり取りが消えている可能性があります。この記事では、警告が出る条件、エラーコードごとの直し方、警告が消えるタイミングを解説します。
なぜ「Transcript writes are failing」が出るか
Claude Codeは作業中の会話を~/.claude/projects/<project>/<session-id>.jsonlへ逐次書き込んでいます。このファイルへの書き込みが失敗すると、入力欄の下に警告が表示されます。警告にはOSのエラーコードが添えられ、原因が名指しされます。
Transcript writes are failing (disk full — ENOSPC) · recent messages may not be saved for resume警告が表示されるタイミングはエラーの種類で変わります。ディスクフル(ENOSPC)、クォータ超過(EDQUOT)、読み取り専用ファイルシステム(EROFS)、パス長超過、macOS・Linuxでの権限エラー(EACCES)は、自然に解消しない条件なので最初の失敗で即座に警告が出ます。それ以外(Windowsでの権限エラーを含む)は、ウイルススキャンなど一時的な要因で1回の書き込みだけ失敗して次のリトライで成功するケースがあるため、1分以上続けて失敗した場合にのみ警告が出る仕組みです。
セッション自体はこの警告が出ていても普通に動作し続けます。会話もツール実行も止まりません。影響を受けるのはディスクへの保存だけです。
Windowsで権限エラーが1分ルールの対象になっているのは理にかなっています。ウイルス対策ソフトがファイルをスキャンしている瞬間だけ書き込みが弾かれ、次の書き込みでは普通に成功することがあるためです。同じ環境で警告が繰り返し出るなら、一時的な取りこぼしではなく、~/.claude/projects(またはCLAUDE_CONFIG_DIRで変更した先)をウイルス対策ソフトのスキャン対象から除外することも検討に値します。1回きりで消えるなら様子見でよく、何度も再発するなら除外設定に進むという切り分けが実務的です。
エラーコード別の直し方
エラーコードごとに対処が決まっているため、警告文をそのまま読んで対応すれば足ります。
| エラーコード | 原因 | 対処 |
|---|---|---|
ENOSPC | 原因ディスク容量不足 | 対処不要なファイルを削除するかディスクを拡張する |
EDQUOT | 原因ユーザー・グループのディスククォータ超過 | 対処クォータを引き上げるか使用量を減らす |
EACCES / EPERM | 原因書き込み権限がない | 対処~/.claude/projects/(またはCLAUDE_CONFIG_DIRで変更した先)の書き込み権限を戻す |
EROFS | 原因ファイルシステムが読み取り専用でマウントされている | 対処書き込み可能な状態でマウントし直す |
| パス長超過 | 原因プロジェクトパスの変換名がファイルシステムの上限を超えた | 対処ディレクトリを浅い階層に移動するか、CLAUDE_CONFIG_DIRで保存先を変更する |
# macOS/Linuxでディスク使用量を確認
df -h ~/.claude
# 権限エラーの場合は書き込み権限を確認
ls -ld ~/.claude/projects原因を直したあとに再度セッションを操作すれば、次の書き込みが成功した時点で警告は自動的に消えます。再起動やセッションの作り直しは不要です。ただし、警告が出ていた間に送った直近のメッセージは、後から--resumeしても復元されない可能性がある点は覚えておく必要があります。
パス長超過は他の4つと違い、ディスクの状態ではなく作業ディレクトリのパスの長さが原因です。トランスクリプトのファイル名は、作業ディレクトリのパスに含まれる英数字以外の文字をハイフンへ置き換えて作られます。変換後の名前が200文字を超えると、Claude Codeは名前を200文字に切り詰め、末尾に元のパスから計算したハッシュを付け足してファイルシステムの上限内に収めます。この処理自体は自動で行われるため、通常は意識する必要がありません。ただし極端に深い階層や長いディレクトリ名を使っている環境では、切り詰め後の名前が別のセッションのものと衝突する可能性はゼロではないため、繰り返しこの原因で警告が出る場合は作業ディレクトリを浅い階層へ移すのが最も確実な対処です。
v2.1.217より前は警告なしで書き込みが失われていた
この警告自体は比較的新しい機能です。v2.1.217より前のClaude Codeは、書き込みに失敗しても何も表示せず、そのままメッセージを取りこぼしていました。ユーザーが異常に気づくのは、後日--resumeしたときに直近のやり取りが見当たらないという形が最初でした。原因の特定も、disk fullのような手がかりが表示されないため難航しがちでした。
現在のバージョンでは、失敗の時点で警告が表示され、原因のエラーコードまで名指しされるため、気づいた時点でディスク容量やパーミッションを直せば被害を最小化できます。v2.1.217のリリースノートではサブエージェントの同時実行数に上限を設ける変更もあわせて入っており、無人運用の安定化を狙った一連の修正の一つに位置づけられます。
意図的にトランスクリプトを保存しない設定との違い
Transcript writes are failingとよく混同されるのが、意図的な保存オフです。原因が違うため、警告文の読み分けが重要になります。
Transcript writes are failing: 保存しようとして失敗している(意図しない状態、直せば直る)CLAUDE_CODE_SKIP_PROMPT_HISTORYが設定されている: 意図的な保存オフ(スクリプトによる使い捨てセッション向け)CLAUDE_CODE_CHILD_SESSIONを継承している: Claude Code自身が起動した子セッションであるための自動的な保存オフ
後者2つはTranscript saving is offという別の文言で表示され、エラーではなく設定の確認メッセージです。--resume一覧に出したくないスクリプト実行では意図的に使う値なので、その場合は対処不要です。意図せず継承していた場合だけ、環境変数を外して再起動します。CLAUDE_CODE_CHILD_SESSIONはClaude Code自身が起動する子セッションに付くマーカーで、バックグラウンドセッションを束ねるagent viewのように複数セッションを親子関係で動かす運用ほど、この継承に遭遇しやすくなります。
長時間セッションでの再発を避ける
ディスクフルによるTranscript writes are failingは、長時間の自動運用セッションで再発しやすい傾向があります。トランスクリプトは既定で30日間保持され、cleanupPeriodDays設定で変更できます。無人運用でセッションを回し続けるチームは、この保持期間を短めに調整するか、CLAUDE_CONFIG_DIRでトランスクリプトの保存先を容量に余裕のあるボリュームへ移すと、同じ警告に繰り返し当たりにくくなります。セッションを快適に保つ運用の工夫もあわせて見ておくと、ディスク以外の要因で長時間セッションが不安定になるのを防ぎやすくなります。
# トランスクリプトの保持期間を14日に短縮する設定例
# ~/.claude/settings.json{
"cleanupPeriodDays": 14
}保存先そのものを変える場合は、CLAUDE_CONFIG_DIR環境変数で~/.claude以外のディレクトリを指定します。容量に余裕のあるディスクへ切り替えれば、同じENOSPCが繰り返し出る状況を根本から避けられます。
SessionEndフックでバックアップする
ディスク容量の管理者権限がなくENOSPCをすぐには直せない環境では、フックで能動的にバックアップを取る回避策があります。Claude Codeのフックはtranscript_pathという入力フィールドを共通して受け取れる仕組みになっており、SessionEndフックを設定しておけば、セッションが終わるたびにそのパスのトランスクリプトを容量に余裕のある別の場所へコピーできます。書き込み先のディスクそのものが詰まっている状態でこの方法が万能というわけではありませんが、~/.claudeとは別のボリュームへ定期的に逃がしておけば、EDQUOTのようにユーザー単位のクォータが原因のケースでは有効な緩和策になります。原因が解消するまでの一時しのぎとして、恒久対応と並行して検討する価値があります。
claude -pの単発実行だけ保存を止める
CIやスクリプトからclaude -pを単発で呼ぶ運用では、その1回だけトランスクリプトを保存したくないケースがあります。この場合はCLAUDE_CODE_SKIP_PROMPT_HISTORYを環境変数として設定するより、--no-session-persistenceフラグを使うほうが適しています。環境変数はシェルプロファイルや呼び出し元プロセスから引き継がれると、意図せず以降のすべての実行に影響してしまいますが、--no-session-persistenceはそのコマンド呼び出し1回に限定されるため、たまたまENOSPCに遭遇したのか、保存を意図的に止めているのかを呼び出し側で明示的に区別できます。
--resumeが使えない間は/exportで内容を確保する
Transcript writes are failingが出ている間に会話が長く続いた場合、--resumeでの復元をあてにせず、/exportコマンドでその時点の会話内容をファイルへ書き出しておくと安全です。/exportはディスクへの逐次書き込みとは別の経路で動くコマンドのため、トランスクリプトの保存が失敗している最中でも、実行した時点の会話は書き出せます。原因を直すまでの間に重要な議論があった場合は、--resumeの復元を待つよりも、その場で/exportしておくほうが確実です。
よくある質問
警告が出ている間、作業を続けても大丈夫ですか
会話とツール実行は問題なく続きます。影響を受けるのはディスクへの保存だけなので、原因を直すまでは通常どおり作業しつつ、直したあとに一度何かメッセージを送って書き込みが成功したことを確認するのが安全です。
警告を消すコマンドはありますか
専用のコマンドはありません。原因のエラーコードに応じてディスク容量や権限を直せば、次の書き込みが成功した時点で自動的に消えます。
すでに欠落したメッセージを復元する方法はありますか
ありません。警告が出ていた間に保存できなかったメッセージは、--resumeで開いても復元されません。原因を直した後のやり取りからは通常どおり保存されます。
この警告が出ているセッションを--continueで再開したらどうなりますか
--continueは--resumeと同じくディスク上のトランスクリプトを読み込んで再開する仕組みなので、影響の受け方は同じです。警告が出ていた間のメッセージは、--continueで再開しても復元されません。次に保存が成功した時点からのやり取りだけが、通常どおり残っています。
まとめ
Transcript writes are failingは、セッションのトランスクリプトをディスクへ書き込めていないことを知らせる警告です。付記されたエラーコード(ENOSPC・EDQUOT・EACCESなど)がそのまま原因なので、対処もコード別に機械的に決まります。会話自体は止まりませんが、警告が出ていた間のメッセージは--resumeしても復元されない点に注意が必要です。v2.1.217以降はこの警告自体が新設された機能で、それ以前は原因不明のまま取りこぼしが起きていました。長時間の無人運用ではディスクフルが再発しやすいため、cleanupPeriodDaysの短縮やCLAUDE_CONFIG_DIRでの保存先変更もあわせて検討する価値があります。