Monitorのpersistentが廃止され30分で監視が切れる理由

Claude CodeのMonitorツールから、期限なしで監視を続けられるpersistent: trueが消えました。v2.1.271で、Monitorの監視はすべて最長30分(-p実行では10分)のデッドラインを持ち、期限が来るとClaudeに再アームを促す通知が届く仕組みに変わっています。v2.1.271のchangelogが置き換えと明記しており、変更自体は意図されたものです。ただしGitHub issueでは、timeout_msのスキーマ上限が実際の挙動と食い違ったままだと報告されています。

Monitorのpersistentは何が変わったか

Monitorツールは、Claudeがログの監視やCIステータスのポーリングをバックグラウンドで続け、変化があったときだけ会話に割り込んで知らせる仕組みです。基本の使い方とWebSocketソースはClaude Code Monitorツールの使い方にあります。Bashのバックグラウンドコマンドにも別の時間制限があり、そちらはバックグラウンドが時間制限で止まる原因で扱っています。

v2.1.271より前は、persistent: trueを指定すればtimeout_msの期限が来ても監視が終了せず、TaskStopで明示的にキャンセルするまで動き続けました。v2.1.271のchangelogは、Monitorの監視を常にデッドライン付きにし、Claudeに再アームを促す通知を送る形に変えたと書いています。期限なしのpersistentオプションは、この変更で置き換えられました。

ツールリファレンスでは、期限は既定で5分です。延長しても最長30分で、-pでの単発実行では最長10分になります。期限に達すると監視は終了し、Claudeは通知を1回受け取ります。まだ必要なら、Claudeが監視を立ち上げ直す運用です。timeout_msの期限はWebSocketのウォッチにも適用され、TaskStopで早めにキャンセルすることもできます。サブエージェントが立ち上げたmonitorは、/tasksなどからそのサブエージェントを止めると一緒に止まります。

同じv2.1.271のchangelogには、auto modeのサンドボックスの項目もあります。Bash・PowerShellに加えてMonitorにもコマンド単位のallowed_domainsが入りました。監視コマンドが必要とするホストだけをその場でレビューし、ほかのホストは拒否します。

30分で切れると何が困るのか

期限切れそのものより、切れてから張り直すまでの空白と往復の費用が問題になります。issue #94393のコメント欄では、次の副作用が報告されています。

• イベントの取りこぼし: 外部プロセスが追記するログをtailする監視では、期限切れから再アームまでの間に書き込まれた行を拾えません。監視が追いつく手段がないため、その間の変化はそのまま失われます
• 再アームの後回し: Claudeが期限切れの通知を受け取っても、別の作業を優先して張り直さないことがあります。あるコメントには、別の「もっと興味深い」作業の最中だったのかもしれない、とClaude自身が診断した、と書かれています
• トークンコスト: 一定間隔で再アームが発生し、イベントの有無にかかわらず費用が積み上がります

費用については、セッションの記録から試算した報告があります。

再アームは「Monitorを呼ぶ」と「締めの返信」の2リクエストで、どちらもコンテキスト全体を読み直すため、この金額になるという説明です。なおv2.1.274のchangelogには、scriptの最終出力と終了を1回の通知にまとめて1ターン節約する変更が載っています。

timeout_msのスキーマ上限が実態とずれている

もう一つの問題は、timeout_msの入力スキーマがこの30分に追随していないことです。issue #94393の報告者は、まずtimeout_ms: 86400000(24時間)を指定する例を試しています。この値はInputValidationError: timeout_ms must be <= 3600000で即座に拒否されました。上限値の3600000(60分)まで下げると呼び出し自体は成功しますが、確認メッセージは「30分で期限切れ」と表示されます。

Anthropic APIではなくClaude Codeのサブスクリプション経由、Windows 11上でも同じ挙動が再現したというコメントがあります。コメントによれば、Linux固有の問題ではなさそうです。

同じコメントは、v2.1.272にバンドルされた型定義sdk-tools.d.tsも引用しています。timeout_msのdocstringは「既定値は300000ms。1800000ms(30分)を超える指定は1800000msに切り詰められる」と実態どおりに更新されていました。一方でバリデーションのmaximumは3600000のままです。受け付けられる値と守られる値が、同じ型定義の中でずれています。

加えてMonitorInputからpersistentが消えた一方、MonitorOutput側には「persistentのときtimeoutMsは0」という説明が残っています。

セッションの一時停止とは別の話

報告者は、セッションの一時停止やidle状態でバックグラウンドタスクが失われる既知のissue(#63023、#65968)とは切り分けて読んでほしいと述べています。報告のセッションは数時間にわたって稼働を続け、Monitor自身が出す期限切れ通知を30分おきに受け取っていました。idleでなくても同じ上限が働くという内容です。

WebFetchの期限にはオプトアウトがある

v2.1.268のchangelogには、WebFetchについて「応答を返さないまま接続を開き続けるサーバーに対し、300秒でフェッチを打ち切る」という項目があります。CLAUDE_CODE_WEBFETCH_DEADLINE_MSで期限を上書きでき、0なら無効になります。

issueのコメントは、同じv2.1.268で入った期限なのにMonitorにはこうした逃げ道がないと指摘しています。継続的な監視が必要な利用者は、期限を受け入れるか、期限のない別の手段に移るかの二択です。

いつから起きていたのか

changelogが仕様変更を明記したのはv2.1.271です。ただしコメント欄を突き合わせると、利用者が体感した変化はそれより前から始まっていました。

30分を超えて監視したいときの手段

期限を持たない手段は2つあります。

Bashのrun_in_backgroundで終了条件つきのコマンドを走らせる

コメント欄で挙がっているのが、終了条件を自前で持つコマンドをBashのrun_in_backgroundで起動する方法です。バックグラウンドのプロセスはMonitorの寿命の対象外で、プロセスが終了するとセッションが呼び起こされます。常時ストリームを受ける代わりに、1回の起動で1回の通知を受け取る形です。

コメントで比較に使われたのは、一定時間後に完了を出力するだけのコマンドでした。

# 指定時間だけスリープしたあとdoneを出力し、プロセス自体が終了する
sleep 2400; echo done

ログの追記を待つ監視をこの形にするなら、tailをそのままパイプにつなぐのではなく、完了マーカーが出るまでポーリングして自分で抜けるループにします。こうすれば、終了条件を満たした時点でプロセスが終わり、完了通知が届きます。

Bashのバックグラウンド実行の仕組みはClaude Codeバックグラウンド実行で扱っています。

プラグインのmonitorsに載せる

もう一つは、プラグインがmonitors/monitors.jsonで宣言する監視です。プラグインのドキュメントは、monitorを「セッション全体を通してバックグラウンドで動くシェルコマンド」と説明しています。コマンドは、セッションを開始した作業ディレクトリのシェルで実行されます。設定方法やwhenトリガーの詳細は、monitors.jsonでプラグインにバックグラウンド監視を組み込むにあります。

experimental.monitorsの各エントリはname・command・descriptionが必須です。whenは省略すると"always"で、セッション開始時とプラグインの再読み込み時に起動します。最小構成は次のとおりです。

{
  "experimental": {
    "monitors": [
      {
        "name": "ci-watch",
        "command": "\"${CLAUDE_PLUGIN_ROOT}\"/scripts/watch-ci.sh",
        "description": "CIステータスの変化",
        "when": "always"
      }
    ]
  }
}

issueのコメントには、v2.1.280での比較検証もあります。「2400秒スリープしてからdoneを出力する」同じコマンドを、Monitorツール(timeout_ms: 3600000)とプラグインのmonitorsの両方で走らせた結果です。Monitorツールは30分で期限切れになり、doneは出ませんでした。プラグインのmonitorsは30分32秒の時点でも生きていて、40分00秒にdoneを出力して終了しています。

手元のclaude plugin validateで見えること

プラグインのエントリは厳密なオブジェクトで、未知のキーは拒否されます。v2.1.289で、一時ディレクトリに作ったプラグインをclaude plugin validateにかけると、旧persistentを持ち込んだエントリは次のように落ちました。

claude plugin validate .
✘ Found 1 error:
 
  ❯ experimental.monitors.0: Unrecognized key: "persistent"
 
✘ Validation failed

descriptionを欠いたエントリはexperimental.monitors: Invalid inputでした。name・description・command・whenだけならValidation passedです。一方、同じpersistent付きのエントリをmonitors/monitors.jsonに置いた場合は、この版のvalidateを通りました。manifestにインラインで書く形のほうが、書き間違いを早く拾えます。

プラグインのmonitorsで起きやすい落とし穴

次の点は、いずれもエラーが出ないまま起こります。

• VS Code拡張では起動しないという報告: ターミナルのCLIで35分以上動いたプラグインのmonitorが、VS Code拡張ではタスクもプロセスも作られなかったそうです。プラグインのmonitorsでは、拡張から30分を超えて動かせないという報告です
• on-skill-invokeにはプラグイン修飾名が要る: スキル名だけでは一致せず、"when": "on-skill-invoke:<plugin>:<skill>"の形で書く必要があるという報告です
• 一度終了したmonitorは再起動しない: 同じセッションでスキルを呼び直しても戻らないという報告です

プラグインの公式ドキュメントにも制約があります。monitorは対話的セッションでのみ動き、-p実行では起動しません。Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryでも動きません。commandは${user_config.*}を参照できず、プラグインを途中で無効にしても、動いているmonitorはセッションの終了まで止まりません。コマンドはmonitors.jsonに固定で書くため、Claudeが会話の流れで監視対象を決めて起動することもできません。

どの手段を選ぶか

イベントを1回受け取れば足りるなら、run_in_backgroundの形が費用も最小です。