- Claude Code
2.1.198 は、AskUserQuestion に 60 秒間応答がない場合、モデルが自己判断で作業を続行する 自動続行機能 をデフォルトで有効化していたが、リリース時点の変更ログやドキュメントには記載していなかった
- 権限リクエストを自動承認することはなかったが、すでに許可されたツールや
--dangerously-skip-permissions 環境では、「staging または production」のような 意思決定ゲート を代わりに通過でき、一部の回答だけを入力しても残りはモデルが選択していた
- 問題提起から約 2 日後に出た
2.1.200 は、機能を削除せずデフォルト値だけをオフにし、/config で 60s, 5m, 10m, never のいずれかを選ぶ オプトイン方式 に切り替えた
- 公開リポジトリには実際の製品ソースや導入・巻き戻しコミットは存在しないが、npm の Bun 実行ファイルに含まれる JavaScript バンドルを比較することで、
2.1.198 で AFK 文字列・スキーマ・分析イベントがまとめて追加されたことを確認できる
- デフォルトの自動更新と不完全な変更履歴が組み合わさると、ユーザーの介入なしに安全前提が変わりうる。CLI を固定しつつプラグインは更新したい場合は、
DISABLE_AUTOUPDATER=1 と FORCE_AUTOUPDATE_PLUGINS=1 を同時に設定する必要がある
60秒後に人の代わりに判断した 2.1.198
- 2026 年 7 月 1 日にリリースされた Claude Code
2.1.198 は、AskUserQuestion が人の回答を 60 秒 待っても得られないとブロックを解除し、モデルに文脈に基づいて最善の判断を下して続行するよう指示していた
- 出力には
No response after 60s — continued without an answer と表示される
- 再質問できる案内もあったが、再質問にも同じタイムアウトが適用された
- ユーザーが一部の質問にだけ答えた状態で席を外すと、入力を破棄せず 部分回答を送信 していた
- 3 つの質問のうち最初にだけ答えると、その回答とモデルが選んだ残りの回答で作業を続行する
- 画面メッセージは、回答状況に応じて
continued with the answers selected so far または continued without an answer を表示する
- 画面にカウントダウンがまったくなかったわけではない
- キーを押すとタイマーが再開し、
auto-continue in 12s · any key to stay のような文言が表示された
- ただし
CLAUDE_AFK_COUNTDOWN_MS のデフォルト値が 20 秒だったため、最初の 40 秒間は通常のブロック質問のように見え、警告は最後の 20 秒間にしか表示されなかった
- 複数のエージェントを別々のタブで実行していたり、席を外していたユーザーは警告を見逃す可能性があった
適用範囲と安全ゲートの限界
- タイムアウトは
AskUserQuestion にだけ適用され、計画承認や Do you want to allow … のような 権限プロンプト には接続されていなかった
- 実行ファイル内では、カウントダウンコンポーネントとタイマーフックは質問ダイアログにのみ接続されている
- ツールリファレンス でも、権限プロンプトはアイドル状態で自動解決されないと明記されている
- 権限プロンプト自体が表示されない実行方式では、この分離は保護策にならなかった
bypassPermissions, acceptEdits, allowedTools, --dangerously-skip-permissions, PreToolUse フックを利用できた
- デプロイコマンドが許可リストに入っていたり、権限確認を迂回していた場合、
AskUserQuestion の「staging または production?」「どの config か?」といった選択が最後に残る唯一のゲートだった可能性がある
- タイマーが権限を付与することはなかったが、すでに権限のある作業の 選択そのものをモデルに任せることができた
- ツールスキーマには
timeout 入力はなく、モデルがこれを設定または制御することもできなかった
- 入力パラメータは
questions, answers, annotations, metadata のみである
- 回答をスキップした主体はモデルではなく、応答を自動返却したエージェントハーネスだった
リリースと巻き戻しのタイムライン
- 確認された公開記録は次の順序で続いている
- 2026-06-29:
2.1.196 リリース、報告者が推定した最後の正常バージョン
- 2026-06-30:
2.1.197 リリース、変更ログには Sonnet 5 リリースの 1 行だけが存在
- 2026-07-01: 自動続行が入った
2.1.198 リリース
- 2026-07-02 02:54 UTC: Aleksey Nogin が イシュー #73125 を登録
- 2026-07-02 03:45 UTC: コメントで非公開の回避策だった
CLAUDE_AFK_TIMEOUT_MS を共有
- 2026-07-02: イシューが開いたままの状態で、24 項目を含む
2.1.199 をリリース、自動続行は依然として未記載
- 2026-07-03:
2.1.200 でデフォルト動作を巻き戻し
- 2026-07-04 18:04 UTC: イシュー終了
- このイシューには 384 件の 👍 と 143 件のコメント が付き、報告環境は
2.1.198、Opus、AWS Bedrock、VS Code ターミナルだった
- 問題報告からデフォルト値の切り替えまで約 2 日 かかった
2.1.200 の修正方法
2.1.200 は機能を削除せず、自動続行を デフォルト無効 にし、/config 経由のオプトインに変更した
- 修正前の
2.1.198 には /config 設定の askUserQuestionTimeout がなく、影響を避けるにはリリース文書に出ていない環境変数を使う必要があった
2.1.211 でも実装全体は維持されている
/config 項目名は Question auto-continue timeout
- 許容値は
60s, 5m, 10m, never
- 設定しなければ
never として扱われ、機能は無効になる
- 内部のデフォルトタイムアウトは依然として 60,000ms、カウントダウン基準は 20,000ms
CLAUDE_AFK_TIMEOUT_MS と CLAUDE_AFK_COUNTDOWN_MS が設定値を上書きできる
- 修正はタイマーを削除したのではなく、設定値または環境変数がある場合にのみ有効化する ゲート条件を 1 つ追加したもの である
- 影響を受けるバージョンに固定されているユーザーは、
settings.json で CLAUDE_AFK_TIMEOUT_MS に非常に大きな値を入れることで一時的に回避できた
変更ログに載っていない機能導入
- リリースノートは公式変更ログとリポジトリの
CHANGELOG.mdに同じ内容で掲載されている
- 当時の記録を固定コミット基準で見ると、自動続行の追加はどのバージョンにも現れない
AskUserQuestionは2.0.55以降の13バージョンで計15回登場するほど、普段は変更ログに記録されていたツールだった
- しかし変更が入った区間である
2.1.181から2.1.200直前までは一度も現れない
- オンとオフという2回の動作変更のうち、オフだけが記録された
- 自動続行を初めて記録した唯一の項目は
2.1.200の「デフォルトではもう自動続行せず、/configでオプトインする」という文言だった
CLAUDE_AFK_TIMEOUT_MSは変更ログにもREADMEにもなかった
動作を巻き戻した後に追加された文書
- 現在の環境変数リファレンスには2つのAFK環境変数が記載され、
2.1.198と2.1.199では60秒の自動続行がデフォルトで有効だったと明記されている
- この文書はリリース当日の状態を記したものではありえない
- 現在の文言が案内する
askUserQuestionTimeoutは2.1.198の実行ファイルに存在しない
- Wayback Machineの6月23日および7月1日12:11・21:35 UTCのキャプチャでは、
CLAUDE_AFKとAskUserQuestionはいずれも0回だった
- 対照項目である
DISABLE_AUTOUPDATERはすべてのキャプチャで2回確認でき、ページ収集失敗による欠落ではなかった
2.1.198は7月1日16:50:16 UTCにnpmへ公開されたが、4時間45分後の文書にもAFK、自動続行、質問ツール、カウントダウンはなかった
- 関連文言は7月1日21:35から7月5日13:58の間に追加され、この区間には
2.1.200での巻き戻しも含まれる
- 新しい文書はすでに「デフォルト無効」になった修正後の状態だけを記録しており、7月1〜2日の実際のデフォルト動作が文書化された時点はなかった
公開リポジトリにない製品ソースとコミット
- 機能を導入した公開コミットも、巻き戻した公開コミットも存在しない
- 公開Git履歴には変更ログと
feed.xmlだけを更新した自動コミット2件が残っている
anthropics/claude-codeリポジトリには追跡対象ファイルが216個あり、そのうち104個がMarkdownで、実際に配布される製品ソースはない
- 実行可能ファイルはサンプルやIssue追跡自動化スクリプトである
plugins/とexamples/にもサンプルプラグイン、GCPゲートウェイのTerraform設定、MDMプロファイルなどが入っている
2.1.197と2.1.198タグの差分はCHANGELOG.mdと、それをRSSに繰り返したfeed.xmlだけである
2.1.196から2.1.206まで10回連続のリリースでも同じ2ファイルしか変わっていない
- タグはソースリリースではなく、実質的にリリースノート用タグである
- 変更ログやリポジトリ・タグ比較では実際の配布動作を確認できず、作成されたソースは公開されないまま、コンパイル済み実行ファイルとしてのみ配布されている
意図的に設計され計測された痕跡
- 公式設計文書、PR、変更ログ文言など、導入理由を確認できる資料はない
- 名前とメッセージは、離席中の人のせいで並列エージェントが無期限にブロックされる状況を狙っていたことを示す状況証拠である
- 内部名
AFKはaway from keyboardを意味する
- メッセージは「ユーザーがキーボードから離れている可能性がある」と仮定する
- Issue参加者は、数十個のエージェントが何日も人の返答を待つワークフローを使っていると明かしていた
2.1.198では、自動解決の有無を示すafkTimeoutMsフィールドがツール結果スキーマに追加された
- 人が答えた経路にはなく、自動解決時にアイドル時間を記録する
- モデルに自動解決された応答であることを知らせ、ターミナル出力コンポーネントを選択するのに使われる
- 同じバージョンに
tengu_ask_user_question_afk_auto_advanceという分析イベントも追加された
timeoutMs、質問数、計画モードかどうか、部分回答の有無を送信する
- 質問本文は送らず、
source_hashとカウンターを使う
hadPartialAnswersが別途計測されていることから、部分回答経路も独立したコードと計測を持っていた
- 動作、カウントダウンUI、スキーマフィールド、分析イベントが1つのバージョンにまとめて入っているため、偶発的な1行ではなく、計測体制を備えた機能だった
- この証拠だけでは、誰が作成・レビュー・承認・マージしたのか、人がどの段階に関与したのかは分からない
クローズドソースだが読めるBun実行ファイル
- インストールされたClaude Codeは約250MBのシンボル未削除ネイティブ実行ファイルである
- Bun単一実行ファイル形式はランタイムの後ろにモジュールグラフを付加し、Claude Code実行ファイルでも
---- Bun! ----の目印が見つかる
- BunはJavaScriptバンドルを実行ファイル内に含めるため、
stringsで設定名、メッセージ、分析イベントなどを読める
- ローカルのインストールディレクトリには最近のバージョンの一部しか残らないが、npmには各バージョンのプラットフォーム別実行ファイルが残っている
@anthropic-ai/claude-codeは約152KBのインストール用スタブである
- 実際のLinux x64向け
2.1.198パッケージは約249MBである
- 公開ソースはないが、各リリースアーティファクトをダウンロードして配布された動作を確認できるため、完全なブラックボックスではない
2.1.197 と 2.1.198 の実行ファイル比較
- 2つの実行ファイルで AFK 関連の文字列を検索すると、境界は明確
2.1.197: away from keyboard、CLAUDE_AFK_TIMEOUT_MS、CLAUDE_AFK_COUNTDOWN_MS はいずれも 0 回
2.1.198: それぞれ 2 回、3 回、3 回出現
- 修正後の
2.1.211 のタイマーゲートには、/config の値または環境変数が存在しなければならないという条件が追加された
2.1.198 にも外部の競合実行の有無などを検査するゲートは存在していた
- ただし、ユーザーが無効化できる条件はなく、修正はここに
&& 条件を1つ追加した形だった
- 機能名と問題が発生したバージョンを知らないまま、一般的なリリース同士を比較するのははるかに難しい
strings -n 8 基準の単純比較では、21,903 個の文字列が異なっていた
- 最小文字列長に応じて 81,289 個または 29,910 個に変わりうるため、21,903 は固定的なリリース特性ではない
- ビルドごとにミニファイアが識別子名を変更するため、大半は実際の機能変更ではないノイズである
- 追加された文字列のうち、大文字で始まり、通常の文の形をしていて、5語以上ある英語文だけに絞ると 156 行まで減る
- その中に
Before going idle the user had selected: が含まれる
- ダイアログが人の代わりに応答する際に会話へ挿入する文字列であり、事前情報なしで読んでもレビューを止めるに値する変化だった
curl、strings、diff で約5分以内に発見できたが、ユーザーがすべての自動更新リリースごとに実行ファイルを検査するやり方は変更ログの代わりにはならない
コストより大きい安全上の問題
- 誤った経路を自動選択すると、不要なトークンを消費する可能性がある
- より大きな問題は、
AskUserQuestion をブロッキングな 安全ゲート と前提していたフックやルールが、60秒のカウントダウンへ変わる点である
- デプロイ、インフラ、本番隣接スクリプトのような危険な環境でも Claude Code は使われている
- Claude Code はデフォルトで自動更新されるため、静かな動作変更と組み合わさると、ユーザーが何もしなくても既存の安全前提が変わりうる
- 最新版を即時に受け取る方針そのものが危険な選択になりうるという議論は、On Cooldowns and Dependabot Tuning につながる
自動更新を無効化する方法と優先順位
- 更新の無効化可否は、次の環境変数を順番に検査し、最初に一致した値が適用される
DISABLE_UPDATES=1: 手動の claude update まで含め、すべての更新経路を遮断
DISABLE_AUTOUPDATER=1: バックグラウンド確認のみ停止し、手動更新は許可。autoUpdates 設定より優先される
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1: 自動更新、フィードバックコマンド、エラー報告、テレメトリをまとめて停止
- シェルプロファイルよりも
~/.claude/settings.json の env ブロックに入れれば、CI、cron、systemd、IDE ターミナルを含むすべてのセッションに適用できる
{
"env": {
"DISABLE_AUTOUPDATER": "1"
}
}
- 設定スコープは、シェルプロファイル、ユーザー別
~/.claude/settings.json、リポジトリ別 .claude/settings.json、中央管理用 managed-settings.json の順に強くなる
managed-settings.json のパスは次のとおり
- macOS:
/Library/Application Support/ClaudeCode/managed-settings.json
- Linux/WSL:
/etc/claude-code/managed-settings.json
- Windows:
C:\Program Files\ClaudeCode\managed-settings.json
- 既存の
C:\ProgramData\ClaudeCode パスは、もはや読み込まれない
- 自動更新を無効化する CLI フラグはなく、
/doctor はインストール種別と更新チャネルを表示する
CLI 更新を無効化するとプラグインも止まる
- 環境変数や
autoUpdates: false など、どの方法であっても自動アップデーターを無効化すると、プラグインの自動更新も停止する
- プラグイン探索ドキュメント では、
DISABLE_AUTOUPDATER と一緒に FORCE_AUTOUPDATE_PLUGINS=1 を設定すれば、CLI は固定しつつプラグインは更新を続けられると案内している
- 一方で、実際の自動更新無効化を案内する
/setup ドキュメント と設定環境変数の表には、プラグインへの影響と FORCE_AUTOUPDATE_PLUGINS の記載がない
- 実行ファイル上でプラグイン更新を止める経路は4つある
DISABLE_UPDATES
DISABLE_AUTOUPDATER
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
autoUpdates: false
- 実行中は、プラグインが止まったという警告の代わりに、デバッグログ
Plugin autoupdate: skipped (auto-updater disabled) が残るだけである
- CLI を固定し、プラグインを維持する設定は次のとおり
{
"env": {
"DISABLE_AUTOUPDATER": "1",
"FORCE_AUTOUPDATE_PLUGINS": "1"
}
}
FORCE_AUTOUPDATE_PLUGINS、DISABLE_AUTOUPDATER、DISABLE_UPDATES は 1、true、yes、on を大文字小文字を区別せず真と解釈し、0 は偽として扱う
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC は値ではなく存在有無のみを検査するため、=0 でも有効化され、この場合は自動アップデーターとプラグイン更新の両方が停止する
更新設定の追加の落とし穴
- プライバシー保護や外部通信制限を目的に
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を使っても、CLI とプラグインは一緒に固定される
- ドキュメントにない
autoUpdates: false は、ネイティブインストールで autoUpdatesProtectedForNative が有効な場合、無視される可能性がある
- 環境変数はこの設定より先に検査され、条件なしで適用される
2.1.98 は、npm インストールで DISABLE_AUTOUPDATER がレジストリのバージョン確認とシンボリックリンク修正を完全には防げなかった問題を修正した
- 自動アップデーターが
~/.local/bin/claude のユーザー定義ランチャーやシンボリックリンクをリリースごとに上書きしていた問題も修正され、現在は /doctor が外部管理ランチャーを表示する
- ネイティブおよび npm インストールはデフォルトで自己更新する
- Homebrew、WinGet、apt、dnf、apk はデフォルトでは自己更新の対象ではない
- Homebrew と WinGet は
CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 でオプトインできる
配布プロセスに残る信頼の問題
- 人が複数のエージェントを同時に監督する場合、60秒以内にすべての質問を確認するのは難しく、誤った選択のあとにどれだけのトークンや作業が消費されるかも事前には分からない
- Anthropic がこの機能の作成、レビュー、承認、マージ、文書化、リリース比較の各段階で、どの人とどの手順を経たのかは公開記録から確認できない
- 機能は約2日で適切なオプトイン形式に修正されたが、日次リリース周期とデフォルト自動更新により、予期しない機能が変更ログなしで配布されうることが明らかになった
- 実行ファイル分析は実際の配布内容を検証する有効な迂回手段だが、正確でよく編集された変更ログの代わりにはならない
- 悪意を前提とする根拠はなく、同種のことが繰り返されるかどうかが、この配布プロセスで何が改善されたかを判断する根拠になる
1件のコメント
Hacker Newsのコメント
Claude Codeチームで AskUserQuestion を作ったThariqです。モデルが強力になるにつれ、長時間の作業が序盤の質問で止まってしまうというフィードバックを受け、それを解決するために変更しましたが、期待していた品質基準には達しておらず、Claude Code本来のリリースのやり方でもありませんでした。
内部評価が良かったとしても、最初からオプトインで提供し、変更履歴にも残すべきでした。AskUserQuestionを安全装置として設計したわけではありませんが、一部のユーザーにとってそのような位置づけになっていたことは理解しています。長時間作業とユーザー入力のバランスを取る別の方法を探し、今回の配布から教訓を得ます
Anthropicほどの規模の会社なら、個人ではなく、この配布を許したPRや組織的プロセスの失敗を認めて是正する姿を見せるべきです
こうした透明性がインターネット時代の新しい流れなのか、技術企業の文化が変わっているのか気になります
「すべての機能が変更履歴に必ず載るわけではない」という文言と、Anthropicが変更履歴をもはや完全な履歴として維持しない理由を明かしていない点が特にもどかしいです。ほかに何がこっそり配布されているのか分かりません(1)
Boris Chernyがその議論でやったのは、GitHub Issueタイトルから「extreme danger」を削除したことだけです(2)。Anthropicがオプションを追加し、デフォルトで無効化したのはまだ救いですが、OpenAIは 60秒の制限時間 を無効化できないままにしています(3)。ただしCodexの実行ツールはより多くがオープンソース化されていて、ユーザーが自分でforkしてオプションを追加できます
トークン費用の補助が終わったら、計算コストまで課金する会社が作った実行ツールは信用しません。今は利害が一致していますが、トークン増加がそのまま利益増加になる瞬間、歪んだインセンティブが大きくなりすぎます。
結局はオープンソースの実行ツールが勝つ可能性が高いので、企業も自らオープンソース化したほうがよいでしょう
最近、ターミナルウィンドウにフォーカスを移そうとしてマウスをクリックしたら、Claude Codeがそれを選択肢のクリックだと解釈して厄介でした
今日まさに自分で体験しました。エージェントの返答を読んでいる最中に質問が出てきたのですが、質問を読み切る前に何かを自動で選択してしまいました。ソフトウェアエンジニアリングはどこへ行ってしまったのでしょう
terraform applyに自動承認フラグを付け加える場面まで見つけ、非常に危険ですClaude Codeがコンピューター上にかなり重い仮想マシンを構成しているようでありながら、デフォルトでは何も サンドボックス隔離 していない点が理解できません。最新モデルはコンピューターを攻撃的に変更し、フロントエンドUIコードのデバッグを頼んだだけなのに、ユーザー権限でアクセス可能なLinuxシステムファイルを書き換え始めました。
サンドボックスに入れてみると、些細な理由で境界を越えようとする試みがどれほど頻繁かが分かり、OpenCodeやローカルLLMを使う理由がさらに強くなります
悪意として解釈する反応も多いが、実際には開発チーム自身が使いたい機能を作ったことに近いように見える。Claude セッションを走らせたまま戻ってきたら、質問ひとつで詰まって何も作業していない状況は、実際かなりもどかしい
Claude が質問してくれることだけが災害を防ぐ唯一の仕組みだと信じるべきでもない。Claude の内部判断ではなく、外部から与えた権限に安全境界を設定すべきだ。一方でこの記事には "Which cuts less far than it looks." のような文があるが、Claude がこれについて質問して止まったとは思えない
LLM にクロスワードを代わりに解かせないのと同じ理由で、楽しさが失われるLLM 作成の散文は投稿しない
悪意があったとは思わないが、無謀で不注意だったし、似たようなことが繰り返されてもチームが学んでいるように見えない。Claude Code は安定して信頼できるツールではなく、最先端の実験に近く、他の実行ツールの代わりに選ぶときに受け入れなければならない代償だ
質問の重大さや想定応答時間を Claude が表示するためのパラメータすらなく、制限時間はたった60秒だった。答えを探そうとしてセカンドモニターで文書を確認して戻る前にスキップされてしまい、60秒では質問の文脈を読むことすら難しい
悪意ではないとしても、アイデアを実際の配布へ移す過程の判断力に大きな空白があることが露呈している
以前、VS Code 向け Codex プラグインにも似た機能が入ったが、すぐに削除された。異なる提供者の LLM が似た発想やバイアスへ収束することは多く、Claude のプロダクトマネージャーや責任者にもLLM が同じアイデアを勧めた可能性があるのか気になる
AskUserQuestion は権限承認の仕組みではないので、デフォルト動作としては問題なさそうに見える。別個の警告機能は必要かもしれないが、モデルが十分によくなって自分で選んで進め、あとでユーザーが修正するほうが、多数のエージェント管理にもやりやすい
Anthropic が Claude Code の動作を丸ごと変えられる点は、Pi コーディングエージェントが作られた理由のひとつでもある。ユーザーが製品の上にかなりの時間をかけて作業フローを構築するなら、一貫性は非常に重要だ