respondToBashCommandsで!コマンド出力への自動応答を止める

Claude Codeの入力欄で!から始めてbashコマンドを打つと、実行結果が会話に取り込まれるだけでなく、Claudeがその出力を見て自動で応答するようになりました。この既定動作を止めて、出力を文脈に入れるだけの従来の挙動に戻す設定がrespondToBashCommandsです。falseにすると、コマンドを何本か続けて打ってからまとめて質問する、という使い方に戻せます。

入力欄の先頭に!を置いてEnterすると、そのシェルコマンドを直接実行する「shell mode」に入ります。git statusやlsのようなコマンドをその場で走らせる機能で、実行結果はセッションに追加され、Claudeがその出力に応答します。respondToBashCommandsが切り替えるのは、この最後の「Claudeが応答する」部分だけで、shell mode自体はv2.1.186より前からある機能です。実行中の処理がなければ、Ctrl+Cを押すと入力欄はいったん空になり、もう一度(空の入力欄で)押すとClaude Codeが終了します。書きかけの!コマンドを誤って消したくないときはCtrl+CではなくCtrl+Sを使います。テキストが入った状態でCtrl+Sを押すと入力を退避して空にし、空の入力欄で再度Ctrl+Sを押すと、カーソル位置や貼り付けた内容ごと、shell modeのまま直前の入力が復元されます。

respondToBashCommandsとは何を切り替える設定か

respondToBashCommandsは、!プレフィックスで実行したシェルコマンドの出力に対して、Claudeが自動で返信するかどうかを切り替えるBoolean設定です。既定値はtrueで、コマンドを打つたびにClaudeがその結果を読んで次の一手を提案したり質問に答えたりします。falseにすると、出力は会話の文脈に追加されるだけになり、Claudeからの返信は起きません。

スコープはAny fileです。設定リファレンスはこの4つをUser(~/.claude/settings.json)・Project(.claude/settings.json)・Local(.claude/settings.local.json)・Managed(組織が配布する設定)と呼び、Any fileはこの4種類のどれに書いても読み込まれることを意味します。複数のファイルに書いた場合は、優先順位の高いファイルの値がそのまま使われます。

v2.1.186で既定動作がどう変わったか

この自動応答はv2.1.186で追加された挙動です。それより前のバージョンでは、!コマンドの出力は文脈に取り込まれるだけで、Claude自身が次の動きを始めることはありませんでした。respondToBashCommandsはこの新しい既定を打ち消すための設定として、同じv2.1.186で用意されています。

CHANGELOGにはこの変更が次のように記載されています。

! bash commands now trigger Claude to respond to the output automatically; set "respondToBashCommands": false in settings.json to keep the previous context-only behavior

つまりfalseは新機能を無効化する設定ではなく、意図的に旧挙動へ戻すためのオプトアウトです。アップデート後に「コマンドを打つたびにClaudeが割り込んでくる」と感じた場合は、settings.jsonにこの1行を足すだけで解消します。

同じv2.1.186では、CLIからclaude mcp loginでMCPサーバーを認証できる変更や、バックグラウンドサブエージェントの権限プロンプトをメインセッションに表示する変更も入りました。単発の修正1件ではなく、確認や認証といった往復のやり取りを減らす方向の更新がまとまって入ったリリースで、bash出力への自動応答もその流れの一つと見られます。コマンドの結果を見てから改めて指示を書く手間を省き、確認と次の一手をひと続きにする狙いがあったためと考えられます。

respondToBashCommands: falseにする設定手順

設定ファイルに直接書く場合は、対象のsettings.jsonにrespondToBashCommandsキーを追加します。個人の全プロジェクトで戻したいなら~/.claude/settings.json、特定のリポジトリだけならコミット対象の.claude/settings.jsonか、コミットしない.claude/settings.local.jsonに置きます。組織全体で強制したい場合はmanaged設定に書くと、ユーザー設定やプロジェクト設定でtrueに戻されても上書きされません。

{
  "respondToBashCommands": false
}

保存後は新しいセッションを開き、!コマンドを1つ打って挙動を見れば設定が反映されているか確認できます。

!git status

respondToBashCommandsがtrueのままなら、この直後にClaudeが変更内容についてコメントを返します。falseにしていれば、出力は表示されるだけで応答は起きません。

trueとfalseの違いは、出力が消えるか残るかではありません。どちらの設定でも!コマンドの出力は会話の文脈に追加され、後続のやり取りでClaudeが参照できます。変わるのは、その追加のタイミングでClaudeが新しい発言(会話上のターン)を作るかどうかだけです。falseのときは出力が黙って文脈に積まれるので、複数のコマンドの結果をまとめて見せてから1つの質問を投げる、という使い方がしやすくなります。

どんな運用で無効化する意味があるか

自動応答が効くかどうかは、!コマンドをどう使っているかで変わります。

git statusやgit diffを連発して状況を一通り把握してから相談したい人ほどfalseが合い、コマンド1本ごとにClaudeとやり取りしたい人は既定のtrueのままで恩恵を受けます。

既定のtrueのまま気をつけたいのは、確認用のコマンドを何本も立て続けに打つ場面です。1本ごとにClaudeが応答を返すため、!ls→!cat package.json→!git log -5のように軽い確認を並べるだけでも、その都度Claudeの発言が挟まります。応答自体は会話の一部としてコンテキストに残るので、単なる下調べのつもりで打った!コマンドの数が多いセッションほど、意図しない解釈や提案が積み重なることもあります。まとまった調査を!で済ませてから相談したい人には、この点がfalseを選ぶ理由になります。

permissions系の設定とは別物

respondToBashCommandsは、Bashコマンドを実行してよいかどうかの確認フローには関与しません。permissions.allowやpermissions.ask、あるいはサンドボックス化されたコマンドを確認プロンプトなしで実行するsandbox.autoAllowBashIfSandboxedは「コマンドを実行する前に確認するか」を決める設定で、respondToBashCommandsは「実行した後の出力にClaudeが応答するか」を決める設定です。前者を厳しくしたまま後者をfalseにしても、コマンドの実行自体が止まったり確認が増えたりすることはありません。逆に、複数行コマンドの自動承認が効かない問題のように、実行前の確認まわりで挙動が変わるケースはrespondToBashCommandsとは別の設定が原因です。

この切り分けは、トラブルシューティングの順番にも影響します。「!コマンドを打っても何も起きない」という相談は、実際には2種類に分かれます。1つはコマンド自体が実行されない、または確認プロンプトで止まっているケースで、これはpermissions関連の設定やサンドボックスの設定を見直す対象です。もう1つはコマンドは実行されて出力も表示されるのに、Claudeからの発言だけが来ないケースで、こちらはrespondToBashCommandsがfalseになっていないかを確認します。出力そのものが表示されているかどうかを先に見れば、どちらの系統の設定を疑うべきかがすぐに切り分けられます。

自動承認とサンドボックスの組み合わせはautoAllowBashIfSandboxedの記事で、複数行コマンドの自動承認が効かない問題は複数行コマンドの自動承認で扱っています。「新機能の既定動作を設定でオプトアウトする」という型自体は、スラッシュコマンドとSkillを丸ごと無効化する--disable-slash-commandsとも共通しています。

よくあるつまずき

respondToBashCommandsをfalseにしても、Claudeがタスクの中で自分の判断でBashツールを呼び出す通常のエージェント動作は変わりません。この設定が対象にするのは、あくまで入力欄で!から始めてユーザーが直接打ったシェルコマンドの出力だけです。Claudeがコード修正の途中でテストコマンドを実行し、その結果を踏まえて次の作業を進める、といった一連の流れはrespondToBashCommandsの影響を受けません。「Bashの実行結果にClaudeが反応しなくなった」ように見えても、原因が別の設定にあることがあるため、!コマンドの出力かエージェントのBashツール呼び出しかをまず切り分けます。

もう一つつまずきやすいのが、複数の設定ファイルに同じキーを書いてしまうケースです。respondToBashCommandsはBoolean値なので、~/.claude/settings.jsonと.claude/settings.jsonの両方に異なる値を書いても両方が合成されることはなく、優先順位の高いファイルの値だけが有効になります。falseにしたはずなのに応答が止まらないときは、より優先順位の高いファイル(managed設定やプロジェクトのlocal設定)にtrueが残っていないかを確認します。配列で指定するキーとは違い、複数ファイルの値を1つにまとめる挙動はしないので、思い当たる設定ファイルを一通り洗い出すのが早道です。User・Project・Local・Managedのどこに書いたかを忘れると原因の切り分けに時間がかかるので、変更したファイルをメモしておくと見直しが楽になります。

まとめ

respondToBashCommandsは、v2.1.186で追加された「!コマンドの出力にClaudeが自動応答する」既定動作を、falseにすることでv2.1.185以前の挙動に戻す設定です。スコープはAny fileなので、個人設定・プロジェクト設定・ローカル設定・managed設定のどこに書いても構いません。falseにしても出力そのものが文脈から消えるわけではなく、変わるのはClaudeが自分から発言するタイミングだけです。コマンドを連発して自分のペースで読み進めたい人や、Claudeの割り込みでテンポが崩れると感じた人は、settings.jsonに1行加えるだけで従来の使い勝手に戻せます。バージョンの詳細はClaude Code v2.1.186のリリースノートにまとめています。