agent viewのpossibly low memoryとは — 起動前の失敗と対処
agent viewの行に出る「possibly low memory — free some up and retry」の意味と、表示される条件、メモリを空けたあとの再開手順をまとめます。
agent viewの行にpossibly low memory — free some up and retryと出たら、バックグラウンドセッションのプロセスが、起動を終える前に、エラーを出さずに終了しています。ホストのメモリも、その瞬間に不足を報告していました。ただしこの表示は仮説で、原因の確定ではありません。メモリを空けてからその行にattachするか返信すれば、supervisorが新しいプロセスを立ち上げ直します。
「possibly low memory」の表示が意味すること
agent viewは、バックグラウンドで動く複数のセッションを1画面に並べる画面です。各セッションは、supervisor(常駐のバックグラウンドサービス)の配下で、それぞれ独立したClaude Codeプロセスとして動きます。
そのプロセスが起動を終える前に終了し、しかもホストのメモリが少ないときに、行のステータスへ終了の理由と次の一文が付きます。
possibly low memory — free some up and retryこの一文は、v2.1.199で入りました。それ以前は、メモリ不足のマシンでバックグラウンドセッションが失敗しても、出るのは汎用的なエラーだけでした。今は「メモリを疑ってよい失敗」だと行を見ただけで分かります。
「possibly」という語が要です。公式の説明も、この注記を仮説であって確定した原因ではないと位置づけています。メモリが本当の原因かもしれないし、たまたま同時にメモリが少なかっただけかもしれません。断定しない表示だと覚えておくと、対処の順序も決まります。
表示が付く条件は3つ
注記は、次の3条件がすべて揃ったときだけ付きます。
- プロセスが、起動を終える前に終了した
- 終了時にエラーを書き出さず、シグナルで止められてもいない(エラーを出さずに終了)
- その瞬間に、ホストがメモリ不足を報告していた
逆に言えば、条件2が外れる場合は別の表示になります。プロセスが終了前にエラーを書き出していたときは、注記ではなくそのエラー自体が行に出ます。
「シグナルで止められていない」という条件も見落とせません。誰かがkillしたプロセスは、エラーを出さずに終わっても、シグナルによる停止として注記の対象外です。OSがメモリ不足を理由にシグナルでプロセスを落とした場合も、公式の条件どおりなら同じ扱いになるはずです。ただし、その場合に行へ何が出るかは公式に書かれていません。低メモリの疑いが濃くても、この注記が出るとは限りません。
注記が出たときの再開手順
やることは3段階です。
- マシンのメモリを空ける(重いアプリやブラウザのタブ、余計なコンテナを止める)
- agent viewで失敗した行を選び、Enterでattachするか、返信を送る
- supervisorが、そのセッション用に新しいプロセスを起動する
会話の履歴はディスクに残っているので、attachや返信の時点で、セッションは中断した場所から再開します。やり直しではありません。
シェルから操作するなら、次のコマンドが使えます。
# 状態を確認する(終了済みも含める)
claude agents --json --all
# IDを指定してattachする(メモリを空けたあと)
claude attach <id>
# 直近の出力を確認する
claude logs <id><id>はclaude agents --jsonのid欄で分かる短いIDです。JSONの読み方はclaude agents --jsonの解説にまとめています。stateがfailedかstoppedになっている行が、再開の候補です。
メモリを空けずにattachすると、また同じ失敗を繰り返す可能性があります。まず空き容量を確認してからattachしてください。Linuxならfree -h、macOSならアクティビティモニタで、メモリ使用量とスワップの状況が見られます。
メモリが足りないままだと何が起きるか
メモリ不足が続くとき、supervisor側にも自動の逃げ道があります。supervisorは、空き資源を確保するために、待機中のセッションのプロセスを自分で停止します。
その基準は、セッションの状態ごとに決まっています。
| セッションの状態 | supervisorの扱い |
|---|---|
| 作業中、権限プロンプトなどのダイアログ待ち、attach中 | supervisorの扱いプロセスを動かし続ける |
| 終了または次のメッセージ待ちで、約1時間attachされていない | supervisorの扱いプロセスを停止して資源を解放する。会話はディスクに残り、次のattachや返信で再開する |
| 予期せず終了した(supervisorは動作中) | supervisorの扱いsupervisorがプロセスを再起動する |
メモリが低いままのときは、この自動停止が働きます。他のアイドルセッションを止めても資源が空かなかった場合は、Ctrl+Tでピン留めしたアイドルセッションのプロセスまで止めます。
ピン留めは「プロセスを動かし続ける」ための印ですが、絶対の保証ではありません。ホストのメモリがよほど逼迫している状況では、ピン留めしたセッションも停止の対象になります。停止は会話を消さないので、次のattachで再開できます。
同じ流れで、失敗が起きた後も、セッション自体は消えません。
行のアイコンと覗き見(peek)で状態を読む
再開する行を選ぶときは、行頭のアイコンを見ます。色とアニメーションがセッションの状態を、形がプロセスの生死を表します。
| 状態 | アイコンの見え方 | 意味 |
|---|---|---|
| Working | アイコンの見え方アニメーション | 意味ツール実行か応答生成の最中 |
| Needs input | アイコンの見え方黄色 | 意味質問や権限の判断など、利用者にしか出せない入力を待っている |
| Idle | アイコンの見え方薄い表示 | 意味用事がなく、次のプロンプト待ち |
| Completed | アイコンの見え方緑 | 意味タスクが成功して終わった |
| Failed | アイコンの見え方赤 | 意味エラーで終わった |
| Stopped | アイコンの見え方グレー | 意味利用者が止めた、または外部からプロセスが終了された |
Stoppedになるのは、Ctrl+Xかclaude stopで止めた場合、プロセスがClaude Codeの外から終了された場合、バックグラウンドサービスが止まっている間に終了した場合の3通りです。メモリを空けてから再開する候補は、FailedかStoppedの行です。
形のほうは、✻か動く✽ならプロセスが生きていて即座に応答します。∙はプロセスが終了した印で、覗き見もattachも返信もできます。/loopのセッションが反復の合間に待っているときは✢です。∙の行に返信すると、Claude Codeが前回の続きから再開します。
覗き見は、行を選んでSpaceを押します。行が端末の端で切っている文を、状態に応じて全部見せてくれます。
- 利用者を待っているセッション: 訊いている質問そのもの(返信欄の上)
- 終わったセッション: その結果
- 作業中のセッション: ステータス文の全体
待機中の行にはwaiting 3mのような経過時間も出ます。返信は入力欄に打ってEnterです。失敗した行の原因を、attachせずに先に確かめたいときに向いています。
一覧上の操作にも触れておきます。Ctrl+Tは選んだ行のピン留めと解除で、ピン留めした行は先頭に固定され、アイドル中もプロセスが維持されます。Ctrl+Xは停止で、2秒以内にもう一度押すとセッションを削除します。削除すると再開できなくなるので、失敗した行を再開したいうちは押さないでください。
「起動前の失敗」と、稼働中に止まる失敗の違い
「low memory」の語は、Claude Codeの別の場面にも出てきます。区別しておくと、原因の切り分けが速くなります。
| 症状 | 起きるタイミング | 見える場所 |
|---|---|---|
| possibly low memory(この記事) | 起きるタイミングセッションのプロセスが起動を終える前に、エラーを出さずに終了 | 見える場所agent viewの行のステータス |
| バックグラウンドタスクの停止 | 起きるタイミング実行中のバックグラウンドシェルが、OSのメモリ圧力通知で止められる | 見える場所タスクの停止メッセージ |
後者は、WSL2で空きメモリが十分にあっても誤検知として出ることがあり、WSL2のlow memory誤検知の解説に原因と回避策があります。そちらは環境変数で止める性質のもので、agent viewのpossibly low memoryとは仕組みが別です。ここで紹介した再開手順は、後者には当てはまりません。
起動失敗の原因を追うときに見る場所
注記の「possibly」に引きずられず、原因を確かめたいときは、ログと状態を見ます。
# supervisorの稼働状況とセッション数を見る
claude daemon status
# supervisorのログを見る
tail -n 50 ~/.claude/daemon.logclaude daemon statusは、supervisorに接続できるか、プロセスIDとバージョン、稼働中のバックグラウンドセッション数を報告します。supervisorのログは~/.claude/daemon.logにあり、セッションごとの状態は~/.claude/jobs/<id>/state.jsonに保存されます。ただしstate.jsonは公式に安定したインターフェースとは扱われていないので、スクリプトから読むならclaude agents --jsonを使います。
低メモリが疑われるのに注記が無いときは、前述の3条件のどれかが外れています。OS側のログも合わせて見ると手がかりが増えます。
起動失敗の理由そのものを機械的に取りたい場合は、CLAUDE_CODE_STARTUP_FAILURE_RESULTSの解説が、別の面(非対話実行の結果ストリーム)の手段を扱っています。
同時に動かす数を絞る
メモリ不足の背景に「同時に動かしすぎ」があるなら、根本の対処は並列数を減らすことです。バックグラウンドセッションは、1本ごとに独立したClaude Codeプロセスです。何本もdispatchすると、そのぶんホストのメモリを消費します。
ワークフローの並列数を抑える手段はMAX_CONCURRENT_AGENTSの解説にあります。今すぐできる手当ては、不要になったセッションを減らすことです。
ピン留めしたセッションを増やしすぎると、その分は動かし続けるプロセスになります。ピンは必要な行だけに絞ると、メモリの余裕を保ちやすくなります。
似た失敗との見分け方
agent viewの失敗行には、possibly low memory以外の表示もあります。行に出た文言で、原因の系統が分かります。
| 行やフッターの表示 | 意味 | 次の操作 |
|---|---|---|
possibly low memory — free some up and retry | 意味起動前にプロセスがエラーを出さずに終了し、ホストのメモリも低かった | 次の操作メモリを空けてattachか返信 |
terminal host process died — press Enter to restart | 意味セッションの端末を担うホストプロセスが終了した(LinuxとWSLで検知) | 次の操作Enterで新しいホストプロセスに再起動 |
Press enter again to restart this session — it isn't responding | 意味開こうとしても約10秒出力が来なかった | 次の操作同じ行でもう一度Enter。シェルならclaude stop <id>のあとclaude attach <id> |
| background serviceが応答しない | 意味supervisor自体が停滞している可能性 | 次の操作claude daemon stop --any --keep-workersで再起動 |
ホストプロセスの死亡や応答なしは、セッションが動き始めたあとの問題です。possibly low memoryは、その手前の起動段階で落ちたときに限られます。supervisorが止まっているときは、行の注記ではなく「background serviceが応答しない」という報告になります。
四つとも、会話は保存されており、再開で続きから動く点は共通です。違うのは、再開の前に手を入れる場所です。メモリなのか、端末ホストなのか、supervisorなのかを、表示文言から先に決めてください。
この注記の読み方
possibly low memoryは、Claude Codeが「エラーを出さない終了 + ホストのメモリ不足」という状況証拠から出す、控えめな示唆です。エラーが書かれていればそちらが優先され、シグナルによる終了なら付きません。
見たときの動きは短く言い切れます。メモリを空け、その行にattachか返信をする。それでも同じ失敗が繰り返されるなら、注記は外れていたと考えて、claude logs <id>や~/.claude/daemon.logで別の原因を探します。