どれくらいの長さの sleep がブロックされるのか？
分からない。changelog にもドキュメントにも「長い」の定義はない。Classmethod の検証では sleep 120 がブロックされたが、それは1つのデータ点であり、しきい値ではない。
最も確実なのは、実際に使っている最長の sleep の値をテスト環境で一度実行して確認することだ。
Monitor と /loop はどちらを使うべきか？
/loop は一定間隔でプロンプトを再実行するもので、Monitor はバックグラウンドで監視し、何か起きたときだけ反応する。条件の成立を待つなら、通常は Monitor のほうがポーリングより安い。
イベントを待つのではなく同じ作業を定期的に繰り返したい場合は、/loop が引き続き適している。
Monitor の30分という上限で足りるか？
何を待つかによる。第三者のまとめでは各監視は最長30分で、期限に達すると Claude は再開できるよう通知を受け取る。それより長い待機は監視の再開でつなぐことになる。
非対話の -p 実行では上限がさらに短い10分で、長いタスクではこの点を計算に入れる必要がある。
アップグレード後にスクリプトが突然止まった場合、sleep のブロックかどうかどう確認するか？
まず出力に「Blocked: standalone sleep」のようなメッセージがないかを見る。あれば、待機を Monitor による条件待ちに変えるか、自分で起動したコマンドをバックグラウンドで実行する。
短い sleep を何度かつないで回避してはいけない。Classmethod が引用するメッセージも、それを避けるよう明確に助言している。
Claude Code v2.1.310（2026年10月23日）の changelog には、Monitor ツールとプラグインの monitor が Bedrock、Vertex、Foundry、およびテレメトリや非必須トラフィックを無効にした環境で使えるようになったと書かれている。同じ項目に、長い前景の sleep もそこで「も」ブロックされるとある。自動化やエージェントが処理の完了待ちに sleep を使う習慣なら、このリリースで止まってしまう可能性がある。
第三者のまとめによれば、Monitor は Claude にログ、CI ジョブ、ディレクトリ、WebSocket をバックグラウンドで監視させ、何か起きたときに反応させる。その間も同じセッションで作業を続けられる。多くの場合 Claude は小さなスクリプトを書いてバックグラウンドで実行し、各出力行をイベントとして受け取る。/loop が間隔を置いてプロンプトを再実行するのに対し、Monitor はポーリングを避ける。制限として、各監視には期限があり、既定で5分、最長30分、非対話の -p 実行では最長10分で、期限に達すると Claude は再開できるよう1回通知を受ける。--resume と --continue はセッション終了時に動いていた monitor を再開しない。Windows では Git Bash が必要で、権限のルールは Bash と同じ、auto モードでは分類器が Bash と同様に Monitor のコマンドを審査する。
これまで Monitor は機能フラグの取得に依存しており、サードパーティのプロバイダーや DISABLE_TELEMETRY などを設定した環境ではその手順が省略されるため、使えなかった。v2.1.310 からは Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry で動く。ツールのリファレンスには Monitor に v2.1.310 以上が必要と書かれ、PushNotification、SendUserFile、RemoteTrigger など他のツールはこれらのプロバイダーでは引き続き使えない。長い前景 sleep の規則には2つの説明がある。Classmethod は macOS で Anthropic API に直接接続し、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 を設定した claude -p で試し、sleep 120 が「Blocked: standalone sleep 120. To wait for a condition, use Monitor with an until-loop.」というメッセージでブロックされ、短い sleep をつないで回避しないよう助言も出たと報告している。別のまとめは、正確なメッセージもしきい値も確認できなかったとしている。長いが何秒を指すのかは changelog にもドキュメントにも定義がなく、Bedrock、Vertex、Foundry 自体での挙動も未検証だ。
プラグインは monitor を自動で起動でき、monitors/monitors.json に名前、コマンド、説明を定義する。when の既定は always で、特定のスキルが初めて実行されたときに起動するようにもできる。注意点は、プラグイン monitor のコマンドはサンドボックスの外で完全なユーザー権限で実行されること、-p 実行ではプラグイン monitor が起動しないこと、コマンドで ${user_config.*} が使えないこと、プラグインを無効にしても実行中の monitor は止まらないことだ。ある形式で使われる experimental キーは、形式が将来変わる可能性も示している。
Bedrock、Vertex、Foundry で Claude Code を動かしているなら、このリリースは新機能であると同時に中断の可能性でもある。テスト環境でスクリプトとプロンプトから sleep による待機を探し、Claude に Monitor で条件の成立を待たせる形に変える。sleep のポーリングはセッションを待機させておくだけで、イベント駆動の待機のほうが通常は安く済む。アップグレード前にしきい値を決めつけず、実際に使っている最長の sleep をテスト環境で一度実行してブロックされるか確認する。プラグイン monitor はサンドボックスの外で動くため、信頼できる提供元のものだけをインストールする。