Claude Code、Codex、OpenCode のどのセッションが止まっているかを見分ける方法（ターミナルを 10 個確認せずに）
「承認待ち」「オフライン」「実際には動いている」を見分ける実践的なワークフロー。まず軽いチェックから始め、使えるならスマホで使いやすい操作ループを使います。
- CLI
- 0.2.17
- プレビュー ref
- a2c45c8
よくある気まずい状況です。
複数のセッション（Claude Code、Codex、OpenCode）が動いている。少しノート PC から離れる。戻ってくると、何かおかしい。
「クラッシュした」というより、こんな感じです。
- 何も進んでいない
- 出力が考えの途中で止まっている
- セッションは「実行中」だが、何かしているのかわからない
つらいのは手間です。セッションが 5〜10 個あると、どれに対応が必要かを突き止めるだけで 20 分かかることがあります。
このガイドは、ひとつの問いにすばやく答えるためのワークフローです。
本当に止まっているのはどのセッションで、どんな止まり方をしているのか？
要点
- 推測しないこと。まず止まり方を分類します。
- 承認待ち / 入力待ち（よくあるケース）
- 切断 / オフライン（マシンのスリープ、Wi-Fi の切断）
- 処理中（まだ動いているが遅い）
- 壊れている（クラッシュした / 固まった）
- 手間の少ないチェック（セッション一覧、最終アクティビティ、ログの末尾をひとつ）から始めます。
- スマホで「いま対応が必要なものは？」を確認するループがほしいなら、Happier はその助けになる選択肢のひとつです。全体の 受信箱（Inbox）と、リクエストの通知ルーティングがあります。
課題（わかりやすく）
「止まったセッション」の多くは、実際には止まっていません。
待っているのです。
- 権限のプロンプトを待っている
- 答えていない質問を待っている
- ノート PC がスリープしてクライアントが切断されたので待っている
これが難しいのは、ターミナルが「これは対応が必要」とは教えてくれず、「このプロセスは存在する」としか教えてくれないからです。
そしてセッションが複数あると、コストがかかるのは修正ではなく診断です。
よくある方法とそのトレードオフ
- セッションの数を減らす：現実的なこともありますが、本格的な作業は並列になりがちです。
- リポジトリごとに tmux のウィンドウを用意し、命名規則を決める：役立ちますが、結局は手作業で見て回ることになります。
- ログを tail する（Codex の log_dir / OpenCode のログ）：役立ちますが、正しいログを開く必要があります。
- Claude Code 組み込みの再開 / 命名機能や Agent Teams の表示：役立ちますが、プロバイダーをまたいだ「対応リスト」にはなりません。
その「対応リスト」をスマホ（またはブラウザ）で使いたいなら、Happier は Claude Code、Codex、OpenCode などのエージェントをクロスデバイスで実行・オーケストレーションできるオープンソースのアプリです。承認やリクエストを一か所にまとめて表示します。
Happier を初めて使う場合（概要と入手方法）
Happier は、Claude Code、Codex、OpenCode などのコーディングセッション向けの オープンソースのコンパニオンアプリ（モバイル / Web / デスクトップ）です。
ワークフローは、セッションを信頼できるマシン（ノート PC / サーバー / 開発マシン）で動かし続け、スマホの Happier から監視、承認、作業の継続を行うというものです。
セットアップ：
- スマホから Happier を使う方法
- GitHub: https://github.com/happier-dev/happier
- インストール / ダウンロード: https://github.com/happier-dev/happier#how-it-works
- Discord: https://discord.gg/W6Pb8KuHfg
うまくいく診断チェックリスト
1) まず：あなたを待っていないか？
セッションが「止まって」いたら、本当に人の判断待ちでブロックされていないかを確認します。
よくあるサイン：
- 最後の出力が質問になっている（「どの選択肢にしますか？」）
- セッションがツールの権限を待っている
- ユーザーの操作が必要なプロバイダー固有のモードになっている（例：プランモードの終了）
Happier を使っているなら、ここで全体の受信箱が役立ちます。承認リクエストや権限 / ユーザーアクションのリクエストがそこに表示され、通知ルーティングは対応が必要なセッションそのものに移動しようとします。
2) 次に：マシンのスリープや Wi-Fi の切断でクライアントが切れていないか？
ノート PC の蓋を閉じた、ネットワークを移った、クライアントがバックグラウンドに回った、という場合、プロセスは問題なくても表示が古くなっていることがあります。
よくある対処はツールによって異なります。
- SSH を使っているなら、この種の問題には Mosh が「移動 + スリープ」に強く、手間の少ない改善策です。
- クライアント / サーバー型のストリーミング UI なら、再接続やストリームの再読み込みが必要なことがあります。
（クライアント / サーバー型のツールで「スリープ後にセッションの状態が古くなる」という実際の報告があります。その場合、対処は「再接続とアップデート」であることが多いです。）
3) その次に：処理中で、遅いだけではないか？
セッションは次のようなときに止まって見えることがあります。
- 大きな差分を処理している
- テストを実行している
- 遅いネットワーク呼び出しを待っている
この場合にほしいのは 進捗のシグナル です。
- 最後のツール呼び出しの時刻
- 最後のファイル編集
- 最後のトークン出力
進捗のシグナルがまったく得られないなら、壊れているものとして次のステップに進みます。
4) 最後に：固まっているものとして扱う（安全な介入を選ぶ）
本当に固まっていると確信したら：
- リスクの低い割り込みを優先する（「止めて、いまどこまで進んだか要約して」）
- そのあと再起動または再開する
セッションの同一性を保ちたいなら、むやみにプロセスを kill しないでください。再開できる仕組みがあるなら、「新しく始めて文脈を貼り付ける」のではなく、resume / attach の経路を使いましょう。
スマホ中心の「対応リスト」ワークフロー（Happier）
多くのセッションを動かしていて診断に時間を取られ続けているなら、Happier が提供する大きな価値は「より強力な機能」ではありません。
探す手間が減る ことです。
-
受信箱が「いま対応が必要なものは？」に答える
-
通知が正しいセッション（と正しいサーバープロファイル）に直接移動する
-
確認が必要（Needs attention）は、あなたの対応待ちでブロックされているセッションをまとめるので、ほかのセッションはひとつずつ確認しなくても動き続けられます
リマインダーでセッションを一時的に脇に置く
止まっているわけではなく、この先 2 時間は気にしなくていいだけのセッションもあります。0.2.13 以降は、意図的に脇に置けます。
- セッションの行のメニューを開き、リマインド（Remind me）を選びます。
- 提案された時刻、日時を選択…（Choose date and time…）、または保存したプリセットを選びます。
リマインダーを設定するとセッションは既読になり、その時刻まで 確認が必要 から外れます。時刻になると、何も新しいことが起きていなくても戻ってきます。0.2.16 以降は、セッションを開くと期限の来たリマインダーが解除されます（手動で解除したい場合は 設定 → セッション → 開いたときにリマインダーを解除（Settings → Session → Clear reminders on open）をオフにします）。リマインダーは Happier のアプリ内での対応状態を変えるもので、プッシュ通知は送りません。詳しくは セッションの既読状態のドキュメント を参照してください。
処理中のセッションを止めずに軌道修正する
セッションが処理中で間違った方向に進んでいるなら、今すぐ挿入（Steer now、0.2.16）が、エージェントがステアリングに対応している場合に、キューのメッセージをターンを中断せずにエージェントへ届けます。今すぐ送信（Send now）は引き続き割り込みます。ステアリング を参照してください。
パソコンの前にいる間はスマホを静かにする
これも 0.2.16 の新機能です。任意の通知設定で、Happier がパソコンでフォーカスされている間はスマホへのプッシュを止められます。パソコンのフォーカスを確認できない場合は、プッシュは引き続きスマホに届きます。
率直なトレードオフ：マシンに到達できることが前提です。
トラブルシューティング
止まっているのか待っているのかわからない
判断を促します。
- 短いメッセージを送る：「私の入力を待っていますか、それともまだ実行中ですか？」
- ツールが対応していれば、1 行の状況報告を求める
セッションを見失ってばかりいる
次のパターンのどれかを使います。
- タスクごとに 1 つのワークツリー / 1 つのセッション
- セッションとリポジトリの一貫した命名
- ひとつの「対応リスト」（受信箱、確認が必要、通知）
- 読んだけれどあとで戻りたいセッションには リマインド の時刻を設定する