Claude Codeのcurrent directoryが消えて終了する — no longer existsの対処
起動直後に「The current directory no longer exists」と出て終了コード1で止まる原因は、シェルが入った後に作業ディレクトリが消えたこと。cdでの直し方とバックグラウンドセッションの同種エラーを解説します。
claudeを実行した直後に次のメッセージが出てプロセスが終了するなら、原因はClaude Codeではなく、シェルが立っているディレクトリがもう存在しないことです。
The current directory no longer exists (it was deleted or moved). Start Claude Code from an existing directory.直し方は単純で、存在するディレクトリへ移ってからclaudeを実行し直します。ただし「ディレクトリを作り直したのに直らない」という落とし穴があり、バックグラウンドセッションでは別の文言で同じ問題が出ます。この記事では、その切り分けと、再発させないためのシェル側の工夫をまとめます。
「The current directory no longer exists」は何が起きているのか
Claude Codeの公式エラー一覧は、このエラーを次のように説明しています。claudeを起動したディレクトリが、シェルがそこに入った後で削除または移動された状態です。例として、別のシェルが消したworktreeや一時ディレクトリが挙げられています。
Claude Codeは作業ディレクトリを読めないため、セッションを始める前に終了コード1で止まります。対話モードでも非対話モード(claude -pなど)でも同じです。
出力される文言は2通りあります。
The current directory no longer exists (it was deleted or moved). Start Claude Code from an existing directory.
error: The current working directory was deleted, so that command didn't work. Please cd into a different directory and try again.公式は「原因と直し方は両方の形で同じ」としています。どちらを見ても対処は変わりません。
v2.1.239より前は生のスタックトレースだった
この親切なメッセージはv2.1.239(2026年8月21日)で入りました。changelogには「存在しないディレクトリから起動したときの生のクラッシュダンプを修正し、明確なメッセージを出すようにした」とあります。
v2.1.239より前は、難読化されたバンドルのソースとENOENT ... uv_cwdのスタックがstderrに出ていました。古いバージョンでその出力を見たなら、同じ原因です。uv_cwdは現在のディレクトリを取得する呼び出しで、ここが失敗していることを示しています。
どうやってディレクトリが消えるのか
起きやすいのは、複数のシェルやエージェントを同時に動かしているときです。ターミナルAでworktreeに入ったまま、ターミナルBや自動化がそのworktreeを削除すると、Aのシェルは消えたディレクトリの中に取り残されます。
# ターミナルA
cd ../feature-x-worktree
# ターミナルB(別のシェルや後始末の処理)
git worktree remove ../feature-x-worktree
# ターミナルAに戻って実行
claude # → The current directory no longer exists ...上は状況を示す例で、公式エラー一覧の例(worktreeや一時ディレクトリを別のシェルが消す)をコマンドに起こしたものです。worktreeの後始末を自動化している場合は、agent viewで.claude/worktreesが溜まる原因と掃除の手順やWorktreeCreate/WorktreeRemove hookの記事にある削除の仕組みが関わっていないかも確認してください。
/tmp配下で作業していて、OSの掃除処理や自分のスクリプトが一時ディレクトリを消した場合も同じ結果になります。
直し方: 存在する場所へ移って起動し直す
起動直後に終了するときの切り分け
- Qメッセージは「no longer exists」で始まりますか?答えがいいえ答えがはい
括弧内がEACCESやEPERMなら、削除ではなく権限の問題です。下の「括弧にEACCESやEPERMが出るときは別の原因」の節へ進みます。
- Qそのパスにディレクトリを作り直していませんか?答えが作り直した答えがはい
シェルは消えた側のディレクトリを握ったままです。
cd "$PWD"で入り直してから、claudeを実行し直します。作り直していないなら、存在するディレクトリ(ホームやプロジェクト)へcdして実行し直します。
claudeが起動する
作業ディレクトリが読めれば、セッションは通常どおり始まります。
公式が挙げる手順は次の2つです。
- 存在するディレクトリ(ホームやプロジェクト)へ
cdしてからclaudeを実行し直す - 同じパスにディレクトリを作り直したなら、
cd "$PWD"を実行するか、いったん出て入り直してからclaudeを実行する
# 作業ディレクトリが消えているかどうかを確かめる
pwd
ls .
# 別の場所へ移って起動し直す
cd ~/projects/my-app && claude
# 同じパスにディレクトリを作り直した場合は、入り直してから起動する
cd "$PWD" && claude作り直したのに直らないのは、シェルがパス名ではなく、消える前のディレクトリそのものを現在地として持っているためです。cd "$PWD"は同じパス名で入り直すので、作り直した新しい側に移れます。パスの文字列は同じでも、これは別のディレクトリへの移動にあたります。
括弧にEACCESやEPERMが出るときは別の原因
削除ではなく、別の理由で作業ディレクトリを読めないときは、文言が変わります。
Can't read the current directory (EACCES). Start Claude Code from a different directory.権限の変更などが原因で、括弧内にエラーコードが入ります。起動する場所を変えるのが基本の対処です。
macOSで~/Desktop・~/Documents・~/Downloads・iCloud Driveのいずれかの中にいてEPERMが出るなら、ターミナルアプリがそのフォルダへのアクセスをmacOSに止められている可能性が高いと公式は書いています。同じフォルダでlsを実行してもOperation not permittedになり、sudoでも変わりません。手順は次のとおりです。
- ターミナルアプリをCmd+Qで終了し、開き直す
- そのフォルダに戻って
claudeを実行する - それでも
lsが失敗するなら、システム設定の「プライバシーとセキュリティ」から「ファイルとフォルダ」を開き、ターミナルアプリにそのフォルダを許可してから再起動する
この場合、ディレクトリは存在しているので、作り直しは意味がありません。メッセージの括弧の中身を最初に見ると、削除と権限の切り分けがすぐ付きます。
バックグラウンドセッションの起動時に出る同種のエラー
agent viewからバックグラウンドセッションを起動したときは、別の文言になります。
Couldn't start a background session (working directory no longer exists or is not accessible: /tmp/demo)セッションを開始している最中に、起動元のディレクトリが消えたときのエラーです。メッセージには消えたディレクトリのパスが入ります。対処は、そのディレクトリを作り直すか、存在するディレクトリから起動し直すことです。
バージョンによる差が2点あります。
| バージョン | 挙動 |
|---|---|
| v2.1.257より前 | 挙動セッションは起動したように見え、agent viewに同じ理由の失敗行として現れた |
| v2.1.257以降 | 挙動起動せず、その場でこのメッセージを出す |
| バージョン | 起動前からディレクトリが無かった場合 |
|---|---|
| v2.1.281より前 | 起動前からディレクトリが無かった場合このメッセージが出た |
| v2.1.281以降 | 起動前からディレクトリが無かった場合「could not be resolved on disk」で報告される |
最後の行のcould not be resolved on diskは、ワークスペースの信頼に関するエラーのひとつです。Claude Codeがセッションのディレクトリを見つけられないときに出て、対処はやはりディレクトリを作り直すか、存在するディレクトリから新しいセッションを始めることです。信頼ダイアログが出せない場所(スクリプトなど)で起動した場合に出る別のメッセージとは、原因が異なります。
セッション中にディレクトリが消えたらどうなるか
ここまでは起動時の話です。起動後にディレクトリが消えた場合のうち、公式のhooksドキュメントに書かれているのはコマンドフックの挙動です。
現在のディレクトリが存在しなくなったとき、Claude Codeはコマンドフックを次の順で、最初に存在するディレクトリから実行します。
- セッションを開始したディレクトリ
- プロジェクトのルート
- ホームディレクトリ
- システムの一時ディレクトリ
どこで実行したかは、デバッグログに警告として残ります。フック内でpwdや相対パスに頼っていると、フォールバック先が変わって結果もずれるため、フックの中では絶対パスのように場所が決まる指定を使う方が確実です。
別のシェルがディレクトリを消して作業ツリーを取り違える類の問題は、Claude Codeが作業ディレクトリを見失う問題の原因と対処法でも扱っています。こちらは起動できなくなるのではなく、動いているのに場所の認識がずれる現象です。ブランチをまたぐ扱いはブランチをまたぐセッションはどう扱われるかに分かれています。
再発を防ぐシェルの工夫
自動化で複数のworktreeを出し入れしているなら、claudeを呼ぶ前に現在地を確かめるラッパーを置くと、このエラーで時間を失わずに済みます。以下は公式にある設定ではなく、cd "$PWD"の挙動を使った例です。
# ~/.zshrc または ~/.bashrc に置く例
claude() {
# 同じパスに入り直す。消えていて入れなければホームへ退避する
cd -- "$PWD" 2>/dev/null || {
echo "作業ディレクトリが無いため ~ に移動します: $PWD" >&2
cd -- "$HOME" || return 1
}
command claude "$@"
}この関数は、ディレクトリが作り直されていれば同じパスに入り直し、消えたままならホームに移ってからclaudeを実行します。ホームはプロジェクトとは別の場所なので、意図しない場所で作業を始めないよう、退避した旨をstderrに出しています。プロジェクトに戻りたいときは、メッセージのパスを見てcdし直します。
CIやバッチで非対話実行している場合は、ラッパーよりも、実行前にcdを明示するのが確実です。非対話モードでも終了コード1で止まるため、ジョブ全体が失敗として検知されます。
# バッチジョブの例: 作業先を明示し、失敗したら終了コードで気づく
cd /srv/jobs/my-app || exit 1
claude -p "テストの失敗原因を要約して"
status=$?
[ "$status" -eq 1 ] && echo "claudeが終了コード1で止まりました。作業ディレクトリを確認してください" >&2
exit "$status"終了コード1はこのエラー以外でも返りうるので、ジョブのログに出力された文言が「no longer exists」で始まるかどうかも合わせて見ると、原因を絞れます。cdに失敗した時点でジョブを止めておけば、消えたディレクトリのままclaudeに進むことはありません。
まとめ
メッセージが「no longer exists」なら、cdで存在する場所に移ってclaudeを実行し直します。作り直したパスならcd "$PWD"が必要です。括弧にEACCESやEPERMがあれば権限の問題で、macOSならターミナルのフォルダ許可を見ます。
バックグラウンドセッションの起動時は別文言で、v2.1.281以降は「起動前から無い」場合がcould not be resolved on diskに分かれます。古いバージョンで生のスタックトレースが出ていたなら、v2.1.239以降へ更新するとメッセージが読めるようになります。