トラブルシューティング

以下に症状を順に示します。該当するものをページ内検索してください。herdr plugin からの Os { NotFound } · update に "not currently on a branch" と表示される · tailscale serve failed · 応答しない (サービスが起動しない) · スマートフォンで URL を開けない · ページは読み込まれるが表示されない (白画面、403) · パスワードプロンプトに入力できない · プッシュ通知が届かない · 再起動後に消える · ペインが狭いまま固定されている · Collie が tmux ウィンドウを開かない · tmux list: output did not parse · herdr plugin list に古いバージョンが表示される · 再ビルド後も UI が古いままになる · Herdrにマシンを保存したが、スマートフォンに表示されない · スマートフォンから開始したアップデートがstagingのまま進まない · macOS 上でのスマートフォンからの更新により Collie がアンロードされたままになる · macOSでcollie statusが「loaded, not running」と表示される · ペインに prompt-cache チップが表示されない · Kiro ペインの History を開いても空である · ペインにChatやHistoryがない · 新しいCodexペインに履歴がまだないと表示される · スマートフォンに、エージェントが表示していない画面をCollieが読み取れない旨が表示される · 送信が3回失敗し、スマートフォンがレポートを提案する · Newページでエージェントがグレーアウト表示される · Startでフォルダーが存在しない、または確認できなかったと表示される · walky talky: send is refused, "run this inside a pane" · walky talky: メッセージがインボックスに残ったままで入力されない · walky talky: "no log record on this machine" · walky talky: スキルが古い · durable agent が表示されない、または Unreachable と表示される。

herdr plugin …がError: Os { code: 2, kind: NotFound, message: "No such file or directory" }で失敗する (プラグインのインストールに失敗する、アクションの実行に失敗する). これはCollieの問題ではなくありません。Herdrサーバーが動作していないため、そのCLIがコントロールソケット(~/.config/herdr/herdr.sock)にアクセスできていません。判断の決め手となるのは生の Os {…}エラーです。サーバーにアクセスできる状態であれば、パスやマニフェストの問題に対して構造化JSON(例: plugin_manifest_not_found)で応答するため、単なるOs { NotFound }エラーが出るのは、Collieやパスの検証が行われる前にソケット接続自体が失敗していることを示します。この問題は、link、install、action invokeなど、サーバーと通信するすべてのサブコマンドで発生しますが、herdr plugin --helpは動作します(ソケットを開かないため)。対処法: 先にHerdrを起動し(herdr server &、またはサーバーを起動するHerdr TUIを立ち上げる)、ls ~/.config/herdr/herdr.sockが存在することを確認してからインストールを再試行してください。herdr plugin listで簡単に確認できます。同じエラーが発生する場合はサーバーが停止しています。

updateがYou are not currently on a branchで失敗します。 0.23.1(#63)以前に行われたGitHubインストールでの問題です。クローンではなくherdr plugin installのデタッチが行われたため、古いupdateにはgit pull先のブランチがありませんでした。修正内容は修正対象のチェックアウト内に含まれているため、適用するには一度再インストールが必要です。必要な3つのコマンドは"You are not currently on a branch" で失敗する場合に記載されています。

startがnote: tailscale serve failedを出力します。 Collie自体は問題ありません（127.0.0.1 で稼働中）。tailnetのingressが起動しなかっただけであり、Tailscale自体のエラーはメッセージの上のターミナルに表示されています。主な原因は、実行ユーザーがTailscaleのoperatorではない（sudo tailscale set --operator=$USER）、ノードがログアウトしている（tailscale up）、またはHeadscale / .internal tailnetドメインでHTTPS証明書が利用できないことです。まさにそのために COLLIE_SERVE_MODE=http が用意されています。.env に設定し、bin/collie restart を実行してください。tailscale serve status で確認します。

serve には HTTPS certificates are not enabled on this tailnet と記載されています。 公開されたものはなく、待機中のものもありません。admin console を開き、「Enable HTTPS」を有効にしてから、collie serve を再実行してください。Headscale / .internal ドメインには有効化する証明書が存在しないため、代わりに COLLIE_SERVE_MODE=http を使用してください。

バナーに⚠ Collie isn't answering on :8787 yetと表示される (サービスが起動しない、connection refused). サービスは開始されましたが、HTTPサーバーがプローブに応答していません。まずユニットを確認し(systemctl --user status collie)、次に原因をbin/collie logs(またはリアルタイム監視ならjournalctl --user -u collie -f)で確認してください。最も多い原因はポートの競合(.envでCOLLIE_PORTを設定し、bin/collie restartを実行。新しいポートに対してtailscale serveも再実行されます)、または初回ビルドの失敗です(ログに記載されます。修正してbin/collie buildを実行してください)。ユニットは5秒ごとに自動再起動するため、原因を解決すれば通常は自動で復旧します。

スマートフォンからtailnet URLを開けない。 次の項目を順に確認してください: (1) スマートフォンでTailscaleアプリが動作しており、ホストと同じtailnetに接続されていること。(2) バナーのtailnet URL(bin/collie url)を開いており、localのURLではないこと(http://127.0.0.1:8787はホスト自身でしか機能しません)。(3) tailnetのDNS設定でMagicDNSが有効になっていること(URLはMagicDNS名です)。(4) ホストがオンラインであること(ホスト側でtailscale statusを確認するか、スマートフォンのTailscaleアプリからホストにpingを実行)。(5) tailnetのポリシーでピアからこのノードへの通信が実際に許可されていること。許可されていない場合、バナーのtailnet行の下にその旨が表示されます。これ以外の方法では判別できません。入り口は正しく公開され、証明書も有効で、ホスト自身からのcurlは200を返します(ループバックはパケットフィルターを通らないため)。この問題を特に見誤りやすくしている要因が2つあります。tailscale pingが成功すること(disco pingはACLをバイパスします)、そしてブロックされたトラフィックは拒絶(refuse)ではなく破棄(drop)されるため、スマートフォン側では単にタイムアウトして「サーバー停止」のように見えることです。ACLポリシー(Tailscaleの場合は<https://login.tailscale.com/admin/acls>、Headscaleの場合はポリシーファイル)で修正してください。この確認機能はベストエフォートであり、過信は禁物です。このノードのフィルターが何も許可していないを許可している場合にのみ警告を表示しますが、これは他のデバイスがまだtailnetに参加していないだけの可能性もあります。判断できない場合は何も表示しません。

ページは読み込まれるが表示されない (白画面、コンテンツが表示されない); API呼び出しが403 cross-origin rejectedで失敗する。 想定外のオリジン(カスタムドメインや、Hostを書き換えるプロキシなど)経由でCollieにアクセスしています。COLLIE_ALLOWED_ORIGINSで正確な公開オリジンを許可するか(設定を参照)、プロキシがHostを変更せずに転送するように設定してください(docs/deployment.mdの4つ目のプロキシ要件)。

sudo(またはSSHパスフレーズ、gpg)のプロンプトで応答が受け付けられない。 Send ではなく、キーボードの上のアクション行にある Type を使用してください。Send は Enter を押す前（34）に画面から入力を読み戻して入力内容を 検証 しますが、パスワードプロンプトではエコーが無効になるため、読み戻すものがありません。Type は Enter を含め、キーストロークをペインに直接送信します。Type で入力した内容は保存されず、下書きに反映されることも、後で復元されることもありません。Collie がパスワードプロンプトを認識した時点で、保存されている下書きも破棄されます（103）。

プッシュ通知が届かない。 手動でテスト送信します: bin/collie push-test。コマンドが判別する原因は、順に次の3つです。pushが無効と表示される場合（キーがブリッジに届いていません。push-keys を実行して再起動してください。Web Push を参照）、登録済みの端末がないと表示される場合（このスマートフォンで「Settings」→「Alerts」が有効化されていません）、送信完了と報告されるのに何も届かない場合（スマートフォンがセキュアコンテキストではない通常のHTTPオリジン上にあります。「Settings」で insecure とフラグが立ちます）。

再起動後にCollieが停止している。 Linux ではほとんどの場合 lingering が原因であるため、loginctl enable-linger $USER を実行してください (再起動後も維持する)。macOS では launchd エージェントが ログイン で起動するため、実際にログインしていること (ログイン画面のままになっていないこと) と、エージェントがロードされていることを確認してください: launchctl print gui/$(id -u)/herdr.collie。

ペインのターミナルが狭いまま固定され、内部のフルスクリーンアプリが潰れて表示される（Copilot CLI、top、またはミラーの残りが空白のまま帯状に描画されるTUI）. ペインのターミナルが実際にその幅であり、Collieはその状態をそのままミラーリングしています。Herdrのペイン幅はタブ内の分割グリッドにおける矩形領域によって決まるため、タブを共有するペインは列数を分け合います。Herdrがペインのジオメトリを適用するのはデスクトップクライアントがアタッチされている間のみ（herdr#1709）です。何もアタッチされていない状態では、分割を閉じても残ったペインは以前の狭い幅のままになり、ソケット経由のpane.zoomやpane.resizeでも変更されません。Collie側からこれを修正することはできません。Collieはペインのジオメトリを一切書き込まないためです（ADR 0031、スマートフォンがオペレーターのターミナルを移動させるのはShow in terminalのタップ時のみです）。これは特定のアプリケーション固有の問題ではありません。54列のペインで実行したtopもまったく同じ表示になります。幅を測定するには、ペイン内でtput colsを実行してください。これが実際の幅であり、herdr pane layoutの報告する値とは異なる場合があります。修正するには、Herdrクライアントをアタッチしたうえでペインをズームまたはリサイズするか（クライアントがアタッチされていればherdr pane zoom <pane-id> --onによってターミナルが移動します）、ペインを閉じて新しく開き直してください（#167）。

Collie が tmux ウィンドウを開かない（スマートフォンの新規タブが拒否され、window-sizeが示される）. リクエストのエラーではありません。3.7未満のtmuxでは、サーバーのwindow-sizeがmanualのときにウィンドウを生成するとサーバー全体がクラッシュし（tmux #4849、3.7で修正済み）、全ウィンドウが巻き添えで消失します。そのためCollieは生成を拒否し、検出したtmuxのバージョンを表示します。対処法は、表示されたコマンド（そのサーバー上でtmux set -g window-size latest）を実行するか、tmux 3.7へ更新することです。他の操作には影響せず、対象ペインでのこれ以外の操作はすべて動作し続けます（要件にも同様の制約があります）。

Collieがtmux list: output did not parseを出力し、ダッシュボードに何も表示されない。 クラッシュではありません。一部のtmuxバージョン（3.6bではなく3.4）は、-Fのリスト出力時にこのアダプターが読み取る区切り文字をエスケープします。Collieは現在両方の形式を読み取るため、パース結果が0行のリストは、空のherdとして保存される代わりにmuxエラーとして報告されます。エラー行にはtmuxのバージョンと検出された行数が示されます。もう1つの原因はロケールでした。UTF-8ロケールなしで起動された場合（最小構成のコンテナ、systemdユニットなど）、tmuxはその区切り文字をエスケープする代わりに_で置き換えます。Collieは現在すべてのtmuxコマンドを-uで実行するため、リスト出力はLANGやLC_ALLに依存しなくなりました。これでも問題が発生する場合は、tmux -Vのバージョンを控えてIssueを開いてください。修正は.envではなくアダプター側で行う必要があります。

updateの実行後もherdr plugin listに古いバージョンが表示される。 正常な動作です。Herdrはインストール時またはリンク時に読み取ったマニフェストをキャッシュします。現在実行中の内容の正式な情報は、フッターのビルドスタンプまたはbin/collie versionで確認できます。リンクされたクローンの場合、updateを実行すると再リンクされて自動修復されます（herdr plugin link "$(pwd)"で強制実行可能）。Herdr ≥0.8.0では、いずれにしてもマニフェストがディスクから再読み込みされます。

リビルド後、スマートフォンに古いUIが表示される。 PWAのService Workerキャッシュはオリジンごとに分かれています。そのため、2つのオリジン（カスタムドメインと生のhost:8787）からCollieにアクセスすると2つの環境がインストールされ、それぞれが独自のバンドルをキャッシュします。フッターのビルドスタンプ（vX.Y.Z · sha · time）は実行中のバンドルを示し、Collieが配信している内容はX-Collie-Buildヘッダーおよび/api/configで確認できます。不一致がある場合、フッターに「新しいビルドがあります — タップして更新」が表示されます。表示されない場合は、PWAを数回開き直すか（Service Workerが自動更新されます）、そのオリジンのサイトデータを削除してください。推奨事項: 使用するHTTPSオリジンを1つに固定してください。（平文HTTPではService Workerが登録できないため常に最新になりますが、PWAの機能は使えません。）

Herdrにマシンを保存したが、スマートフォンに表示されない。 これは想定された動作です。Herdrに保存されたマシンはHerdrクライアント独自の一覧であり、crewはCollie独自の一覧です。両者の一覧が同期されることはありません。スマートフォンからそのマシンにアクセスするには、登録を行ってください。leadでcollie crew add <ssh-host>を実行し、次にleadでcollie restartを実行してから、collie crew statusでリンクを確認します。Herdr側でマシンを追加または削除しても、crew側には一切影響しません（Herdrのマシンとcrew）。

ペインに prompt-cache チップが表示されません。 考えられる原因は3つあり、collie doctor で判別できます。ペインの harness に journal アダプターがない場合（integration-<agent> 行と journal-roots 行に表示）、ペインからセッションが報告されていない場合（agent-sessions 行にペイン ID 別に表示）、またはエージェントがまだターンを実行していない場合です。最後のケースは異常ではありません。計測されるまで何も表示されないため、エージェントの最初の応答時にチップが表示されます。ベンダーがキャッシュの有効期間を公開していない harness でも表示されません。本ビルドに含まれる全ルールは cache-claims に記載されています。

Kiro ペインの History を開いても空のままです。 ペインの Kiro がセッションロックを保持しているか確認します。

cat ~/.kiro/sessions/*/*/.lock

Herdr は Kiro ペインのセッションを指定しないため、Collie は実行中の Kiro が保持するロックによって検出します。これは、ペインのフォアグラウンドプロセスを一覧表示できる唯一のマルチプレクサである Herdr 上でのみ、かつそこで正確に1つの Kiro プロセスが実行されている場合にのみ機能します。それ以外の場合、History にはペインにエージェントセッションがないと表示されます。

Collie は、--v3 または --agent-engine v3 で開始された Kiro V3 セッション、あるいは Kiro 自身の設定でエンジンとして V3 が設定されたセッションを読み取ります。該当ペインでその方法で Kiro を再起動してください。Kiro にインストールする Herdr フックはありません。セッションが別の場所にある場合は、kiro_root を設定してから collie restart を実行してください。

Chat が表示されるはずのペインにターミナルが表示されます。 エージェントペインのデフォルトはChatであるため、次の2つのいずれかが該当します。以前にこのデバイスでターミナルが選択された場合は、ペインの⋮メニューを開いてChatビューをタップします。または、ペインにセッションがないか、読み取るログがありません。新しいペインは「Send a message to start」とともにChatを表示し、最初のターンが読み取るものなしで終了した場合、または最初に質問を投げかけてきた場合にはターミナルにフォールバックします。メニュー行にはどの部分が不足しているかが示されます。手順は次の項目を参照してください。

ペインに Chat も History もなく、⋮ メニューに「ペインがセッションを指定していません」と表示されます。 Chat と History はエージェントのセッションログを読み取ります。Collie がログを見つけられるのは、エージェントがマルチプレクサ経由で自身のセッションを報告した場合のみです。Herdr では、この報告はエージェント自体の統合機能から行われるため、それが存在しないか古い場合は、他の症状が出ないまま両方が非表示になります。collie doctor は agent-sessions にペイン名を、integration-<agent> に修正方法を示します。

1. 01
   herdr integration status を実行してください。エージェントが not installed または outdated の場合は、herdr integration install <agent> を実行します。Oh My Pi は omp、pi は pi であり、それぞれ固有のものが必要です。
2. 02
   該当するペインでエージェントを再起動してください。エージェントは起動時にフックを読み込むため、インストール中に実行中だったエージェントは何も報告しない状態が続きます。
3. 03
   フックが最新で、再起動したペインが依然として何も報告しない場合は、別のエージェントが開いたシェルからそのエージェントが起動されたか確認してください。親エージェントから OMPCODE=1 が継承されている場合、Oh My Pi のフックは機能しません。新しいターミナルから起動してください。

tmux、zellij、tern では、Collie のビーコンフックを経由してセッションを報告するのは Claude Code のみです。collie hooks install claude（Collie は Claude 自身の設定にフックを書き込みます）を実行してください。他のエージェントには、そこでの Chat や History がありません。

新しいCodexペインに履歴がまだないと表示される場合。 最初のターンまでは想定どおりの動作です。Codexは起動時ではなく、最初のプロンプトが送信されたときに初めてHerdrへセッションを報告します。そのため、新しいペインにはそれまでセッションがなく、Historyリンクもありません。collie doctor は該当ペインを未報告として agent-sessions の下に一覧表示し、障害としてはカウントしません。Codexが応答した後もこの表示が消えない場合は、Codexで /hooks を開いてください。フックが変更されるとCodexから確認を求められますが、「Continue without trusting」を選択すると、herdr integration status 上は最新と表示されたままでもHerdrフックが無効になります。そこでフックを信頼するか、herdr integration install codex を実行して新しいセッションを開始してください。

デスクのエージェントには通常のプロンプトが表示されているのに、スマートフォン側ではCollieがダイアログを読み取れないと表示される、または送信した入力が入力欄に届かない。 Collieが画面を誤読しています。通常はエージェントによる描画方法の変更が原因です。スクリーンショットでは確認できない情報（Collieが読み取る色や薄暗いテキスト）を含む画面の生テキストを添えて、Issueを作成してください。herdr pane list でペインIDを確認し、次を実行します:

herdr pane read <pane-id> --source recent --lines 200 --format ansi > pane.txt

スマートフォン側に問題が表示された状態のまま実行し、エージェントのバージョン（claude --version、codex --version など）と合わせて pane.txt を添付してください。このファイルにはターミナルのテキストが含まれるため、事前に内容を確認し、機密情報が含まれる場合は削除してください。

送信が3回失敗し、スマートフォンがレポートを提案する。 1つのペインでCollieに起因する理由により送信が3回連続で失敗しました: 入力ボックスの読み書きができなかった、テキストが入力されたのにEnterが続かなかった、または送信の追跡を見失った場合です。ユーザーを保護するための拒否（ボックス内の下書き、実行中のターン、開いているダイアログ）はカウントされません。カード上の Report をタップしてください。シートには、送信が行われる前にIssueの全体が表示されます: Collieとエージェントのバージョン、マルチプレクサ、および失敗した各送信のコードです。入力したテキストは含まれず、入力内容を含める または 画面を含める を有効にしない限り画面も含まれません。画面はペインの最新40行で、既知のシークレットの形式はマスクされます。Issueは公開されるため、事前に内容を確認してください。Open on GitHub は入力済みのフォームをお使いのブラウザで、自身のGitHubアカウントで開きます。Copy report は同じテキストをコピーします。同じシグネチャ行を持つIssueを検索するには、まず 報告済みですか？ をタップしてください。ペインメニューおよび 設定 → システム からは、いつでも同じシートを開くことができます。バツ印を押すと、送信が再び成功するまでそのペインのカードを閉じます。クルーメンバーのペインではまだレポートを提案しません。上記の手順を使用してください。

スマートフォンから開始したアップデートがstagingのまま進まない。 Collie 1.6.0以前では、スマートフォンでアップデートをタップした際に、新バージョンのステージング後に処理が停止することがありました。切り替えを実行するrunnerが起動せず、サービスは古いバージョンを提供し続け、実行レコードはロックを保持したままstagingにとどまります。この問題は、collie update --statusがstaging（10分経過後はinterrupted — the updater is gone）を報告すること、versions/の下に新リリースのバージョンディレクトリが存在すること、~/.config/collie/collie.logのrunnerログが0バイトであることの3つの条件が揃うことで確認できます。同じマシン上のシェルでcollie updateを入力した場合は正常に動作していましたが、これも同じ不具合の別側面です。次のリリース以降で修正されています。ハンドオフ時にユーザーマネージャーによるrunnerの確認を待つようになり、ハンドオフが拒否された場合はマネージャー自身の理由とともに失敗として報告されます。

すでに停止しているマシンを復旧するには、10分間何も操作しないでください。アップデータが終了した実行は、最後の状態遷移から10分経過すると再試行のブロックを解除し、次回のタップで処理が進みます。今すぐ復旧するには、レコード、ロック、ステージング進行状況ファイルを削除し、--statusの出力を確認してください:

collie update --status            # note the pid it names
ps -p <pid> -o command=           # empty output: the updater really is gone
rm -f ~/.local/state/collie/update.json ~/.local/state/collie/update.lock
rm -f ~/.local/state/collie/update-staging-*.log
collie update --status            # "no update has run on this install yet"

古い実行をクリアするコマンドはなく、これら3つのファイルが停止したステージングの残す状態のすべてです。サフィックス付きインスタンスでは、これらは代わりに~/.local/state/collie-<name>/に保持されます。アップデートが実際に実行されている間は絶対に削除しないでください。まずPIDを確認してください。ロックを削除した状態で実行中のアップデータがあると、保護なしでcurrentが切り替わってしまいます。versions/はそのままにしておいてください。中途半端にステージングされたバージョンディレクトリは無害であり、再試行時にその中に再ビルドされ、不要になったものは保持スイープによって削除されます。

macOS 上でのスマートフォンからの更新により Collie がアンロードされたままになります。 Mac 上で以下を実行します。

collie restart

1.8.x までの Collie では、スマートフォン側でアップデートをタップした際に launchd エージェントが停止し、二度とロードされなくなることがありました。これによりスマートフォンからサービスを見失い、launchctl print gui/$(id -u)/herdr.collie は何も検出できなくなります。ランナーがエージェントのプロセスグループを共有していたため、エージェントを再起動すると途中で終了していました。collie restart はエージェントの plist を書き直してロードします。1.9.0 以降では、bridge が独自のプロセスセッションでランナーを起動します。それでもスマートフォンのアップデート後にエージェントがアンロードされる場合は、同じコマンドを実行して #213 に注記を追加してください。

macOS で、collie start は完了するものの collie status に "loaded, not running" と表示されます。 launchd ジョブはロードされていますがプロセスが動作していないため、ログは空です。ジョブを手動で起動してください:

launchctl kickstart gui/$(id -u)/herdr.collie
collie status

サフィックス付きのインスタンスには、herdr.collie-next のような独自のラベルが付きます。1.17.0 以降では collie start および collie restart がこの手順を自動で行い、プロセスが起動しない場合はこのコマンドを含む警告を出力します。その後もジョブが "loaded, not running" のままになる場合は、collie logs でログを確認し、#213 に報告を追加してください。

Newページでエージェントがグレーアウト表示される。 名前の後の括弧内に理由が示されます。「not installed」は、ログインシェルが使用するPATH上で、マシンがエージェントのコマンドを見つけられなかったことを意味します。該当マシンのログインシェルでbash -lc 'command -v claude'（またはエージェント名自体）を実行してください。何も出力されない場合は、そのマシンにエージェントをインストールするか、シェルのログインファイルでPATHに追加している行を修正し、ページを再度開いてください。クルー環境では、選択したマシンを確認してください。各メンバーは自身のディスク内を検索します。「this machine runs an older Collie」と表示される場合は、そのメンバーを更新してください（マシン上で何かを開始する）。「needs Herdr」およびマシン名付きの「only on」は、エージェントではなく新しいworktreeスイッチに該当する表示です。

Startで「There is no folder … on this machine」または「could not confirm the start」と表示される。 1つ目は、起動を実行するマシン上にフォルダーが存在しないため、何も起動しなかったことを意味します。先頭に/や~が付いていない名前はホーム配下のフォルダーを指すため、projectsは~/projectsを意味します。フォルダーを作成するか、Recentからフォルダーを選択してください。2つ目は、スマートフォンが応答を受信できなかったことを意味します。ペインが既に存在する可能性があるため、まずダッシュボードを確認してください。再試行は同一のリクエストを送信するため、ペインが重複して開くことはありません（スマートフォンからエージェントまたはシェルを起動）。

トランシーバー

walky talky で最もよく発生する現象は6つあります。それぞれに原因を示すコマンドが用意されています（トランシーバー）。

collie walky send に「run this inside a pane, or send from the phone」と表示されます。 通常のターミナルなど、エージェントのペイン外でコマンドが実行されました。Collie はペイン自身の環境から送信者を特定します。ペインのない送信は拒否されます。エージェントのペイン内でコマンドを実行するか、スマートフォンから送信してください。エージェントペイン内では、collie walky who がペインを (you) でマークします。「no Collie bridge on this machine knows this pane」というエラーは、別の Collie がペインを所有していることを意味します。「no running Collie bridge answers」というエラーはブリッジが停止していることを示します。collie status を実行してください。

メッセージに「held」と表示され、まだ入力されていません。 collie walky status <id> が「held: draft present」または「held: turn running」を出力します。入力欄に下書きがあるか、エージェントが処理中です。Collie は入力欄が空くかターンが終了した時点でメッセージを入力します（最大60分間）。再送信はしないでください。すぐに通すには、該当ペインの下書きを送信するか消去してください。古い lead の場合、「queued (outcome known on the lead)」も待機を意味します。

メッセージが inbox に置かれたままで、入力されませんでした。 collie walky status <id> が「waiting in the inbox, not typed」とその理由を出力します。「held past 60 minutes」は、下書きの残存、ペインのビジー状態、またはダイアログが開いた状態が60分の保持期間全体にわたって続いたことを意味します。Collie は下書きやダイアログに入力しません。「box not free」は空の入力欄を読み取れなかったことを意味します。「pane busy」は前のメッセージが2分経過後もまだ入力中だったことを意味します。「pane replaced」はメッセージの待機中に別のセッションがペインを引き継いだことを意味します。その他の理由として「no terminal」と「bridge restarted」があります。該当ペインで collie walky inbox を実行するか、スマートフォンのペインメニューから Messages を開いてください。Collie がメッセージを再入力することはありません。

collie walky send に「not sent: pane replaced」と表示されます。 アドレスの末尾が #k3f9 などのトークンで終わっており、指定されたペインが閉じられています。現在は別のペインがそのペイン ID を保持しているため、Collie はそこへメッセージを入力しません。collie walky who を実行し、新しいアドレスに送信してください。「not sent: sender gone」となる返信も原因は同じです。送信元ペインが閉じられたか、別のペインがその ID を現在保持しています。

ペイン内のヘッダーに「no log record on this machine」と表示されます。 スマートフォンが画面テキスト内の walky talky ヘッダーを検出しましたが、このマシンのログに該当 ID のメッセージがありません。誰かまたは何かが該当行を入力したか、7日経過または2,000行を超えてログから削除されたか、別の Collie が保持しています。collie walky status <id> を実行してください。「no record of <id> on this machine」と出力されればそれが確認できます。crew メンバー上のペインについては、そのメンバー上で実行してください。スマートフォンが読み取ったのはそのメンバーのログです。その行はプレーンテキストとして扱い、必要であれば送信元に問い合わせてください。

skill が古くなっています。 collie doctor が skill-walky-talky 行目で警告を出し、エージェントが古い指示に従っています。指示ファイル内のテキストがこのビルドと異なっています。collie skill status を実行して、どの harness が遅れているか確認してください。スクリプト内では collie skill status --check を実行します。コピーが古い場合は何も出力せず終了コード3で終了します。collie skill install all で修正し、エージェントを再起動してください。refused とマークされたターゲットはシンボリックリンクであるかマーカーが破損しており、インストール処理が変更を加えることはありません。

durable agent

アタッチした durable agent には、独自のチェック、理由、ケースがあります。まずは collie durable list と collie doctor から始め、その後に durable agentのトラブルシューティング を参照してください。