Claude Codeで毎回「許可しますか」と聞かれる原因と設定｜cd・&&つきコマンドで止まる罠【2026年】

Claude Codeで同じコマンドなのに毎回許可を聞かれるのは、許可ルール（allow）が無いか、ルールの形がコマンドと合っていないためです。&& や ; でつないだコマンドは1つずつ照合されるので、1か所でも外れると聞かれます。/permissions で今のルールを確かめ、settings.json にルールを足せば止まります。

「Do you want to proceed?」と毎回聞かれる4つの原因

Claude Codeがコマンドを実行する前に出す確認画面には、This command requires approval と Do you want to proceed? が表示されます。2026年10月時点の公式ドキュメントに照らすと、毎回これが出る原因は大きく次の4つです。

許可ルールとは、どのツールやコマンドを確認なしで動かしてよいか（allow）、必ず確認するか（ask）、禁止するか（deny）を、設定ファイルに1行ずつ書いておく仕組みです。

原因1：「Yes」だけを選んでいて、ルールが保存されていない

確認画面の「Yes」は、その1回だけの許可です。次回から聞かれなくするには「Yes, and don't ask again」を選ぶ必要があります。公式の表では、Bashのコマンドはこの選択で「リポジトリとコマンドごとに恒久的に」許可され、ファイル編集は「セッションが終わるまで」の許可です。つまり、ファイル編集は新しいセッションを始めるたびに、また聞かれます。

原因2：ルールの書き方がコマンドと合っていない

Bashの許可ルールは、Bash(npm run *) のように、コマンドの文字列と照合します。* の前に書いた部分はそのまま比べられるので、書き方が少し違うだけで外れます。

• Bash(npm run build) は npm run build だけに合い、npm run build --watch には合いません
• Bash(ls *) は ls と ls -la に合いますが、lsof には合いません（* の前の空白もルールの一部です）

原因3：&&・;・| でつないだコマンドや、cd・変数代入が混ざっている

複合コマンドとは、&&・||・;・| などで複数のコマンドを1行につないだものです。公式ドキュメントでは、ルールはつないだ一つひとつのコマンドに別々に合う必要があると説明されています。Bash(python3 *) を許可していても、python3 build.py && 別のコマンド は、後ろのコマンドにルールが無ければ聞かれます。

cd にも注意点があります。作業フォルダの中への cd は読み取り専用として扱われ、cd packages/api && ls のように各部分が条件を満たせば確認は出ません。ただし、cd で別のフォルダに移ってから git を動かす組み合わせは、各部分が読み取りでも確認が出ます。移った先のフォルダの仕掛け（gitのフック）が動く可能性があるためです。

先頭の変数代入（E=値 コマンド の形）も外れる原因です。公式によると、安全と分かっている一部の環境変数以外の代入が先頭にあると、allowルールはその先のコマンドに合いません。

原因4：ask・denyのルールや、許可モードが優先されている

ルールは deny → ask → allow の順に評価され、最初に当たったもので決まります。細かいallowルールを書いても、広いaskルールに当たれば確認が出ます。許可モードが Manual（設定値は default）のときは、読み取り以外は基本的に確認が出ます。

原因と対処の早見表

allowルールで「許可しますか」を止める設定手順

聞かれなくする設定は、軽いものから順に試します。設定ファイルを直接書く前に、まず今のルールを見るのが近道です。

1. 今のルールを確かめる：Claude Codeの中で /permissions を実行します。公式によると、この画面にはすべての許可ルールと、各ルールがどの settings.json から来ているかが一覧で出ます。
2. 確認画面で「Yes, and don't ask again」を選ぶ：Bashのコマンドなら、gitリポジトリの根にある .claude/settings.local.json にルールが保存され、そのリポジトリの次のセッションからも効きます。つないだコマンドを承認した場合は、確認が要る部分ごとに別のルールが保存されます（1回で最大5件）。
3. 設定ファイルにまとめて書く：何度も使うコマンドは、settings.json の permissions に直接書いたほうが早いです。設定例はこの手順の下に示します。
4. * はサブコマンドの後ろに置く：Bash(git log *) は git log だけを許可しますが、Bash(git *) はgitのすべてを許可します。
5. 置き場所を決める：自分のパソコン全体なら ~/.claude/settings.json、チームで共有するならプロジェクトの .claude/settings.json、自分だけなら .claude/settings.local.json です。複数あるときは、管理者配布 → local → プロジェクト → ユーザーの順に優先されます。
6. ファイル編集の確認が多いなら許可モードを変える：許可モードとは、確認なしで実行してよい範囲をまとめて決める設定です。Shift＋Tab で切り替えられ、acceptEdits にすると、作業フォルダ内のファイル編集と mkdir・mv・cp などの基本コマンドが確認なしになります。毎回このモードで始めたいなら permissions.defaultMode に書きます。
7. 新しいセッションで確かめる：同じコマンドを1回実行させ、確認が出ないことを見ます。

手順3の設定例です。公式の例と同じ形で、npmのスクリプトとgitのコミットを確認なしにし、git push で始まるものは拒否します。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

許可モード6種類の違いは、Claude Codeの使い方ガイドの許可モードの章にまとめています。

cd・echo・変数代入を混ぜたコマンドで、無人の定期タスクが約4時間止まった記録

ここからは、僕の会社（株式会社UrakaTA）で実際に起きたことです。当社は、このメディアの情報収集や記事の公開を、Claude Codeの定期タスクとして毎日無人で動かしています。

何が起きたか：朝の2本が許可待ちのまま止まった

2026年10月2日の朝、定期タスクの初回実行で、6時12分に始まる情報収集と、7時02分に始まる公開の2本が、許可の確認画面のまま止まりました。原因は、AIがその場の判断で書いた、echo・cd・変数代入を混ぜたコマンドです。allowルールに合わない形だったので確認画面が出ましたが、無人なので答える人がいません。

気づいてから手で再実行し、情報収集は10時38分、公開は11時09分に動き直しました。朝の予定から約4時間の遅れです。

その日の午後も同じことが続きました。今度は、執筆や検品を任せたサブエージェント（作業を分担させる別のAI）が、curl やアプリ内ブラウザ、作業フォルダの外を探す find などを即興で使い、確認画面で止まりました。社内のフックの導入記録では、この日だけで許可待ちの停止が5回あります。

1回目の対策：「無人実行の鉄則」を全タスクの冒頭に書いた

最初に、定期タスクの指示文すべての冒頭に、社内で「無人実行の鉄則」と呼んでいるルールを足しました。今の要点は次のとおりです。

• Bashは1回の呼び出しで1コマンドだけ。;・&&・|| でつながない
• cd・変数代入・echo・$(...) を使わず、パスは毎回フルパスで書く
• 使ってよいコマンドを列挙し、それ以外が要るときはPythonのスクリプトかファイル編集で代わりにやる
• サブエージェントへの指示文の先頭にも、このルールを丸ごと貼る（午後の停止を受けて足した項目）

あわせて、ユーザー設定のallowに cd と echo を足しました。ただ、ルールを書いても、AIが毎回守るとは限りません。サブエージェントは定期タスクの指示文を読まないので、午後の停止はそこから起きました。

2回目の対策：無人のときだけ、確認画面を自動で「拒否」にするフック

そこで、PermissionRequestのフックを入れました。PermissionRequestとは、ツールの呼び出しに許可の判断が必要になったとき、確認画面を出す前に動くフックのイベントです。フックから許可か拒否を返せます。

当社のフックは、セッションの記録の冒頭に「定期タスクから起動された」という印があるかを見て、印があるときだけ「拒否」を返します。拒否の文には「許可済みの方法で続けるか、その作業は保留にしてログに理由を書く」と入れてあり、AIは止まらずに別の方法を選びます。普段の対話セッションでは何も返さないので、これまでどおり確認画面が出ます。拒否した操作は1行ずつログに残し、許可リストの見直しに使っています。

フックを入れた後、10月2日18時20分に、既存記事を直して本番に反映する改善タスクが、初めて最後まで無人で完走しました。翌10月3日に拒否ログに残ったのは2件で、どちらも検品役のサブエージェントが、複数行のPythonスクリプトや、引用符の中にバッククォートを含む grep を1回で実行しようとしたものでした。公式も、解析しきれないコマンドは読み取り専用と見なさず確認を出すと書いています。フックが無ければ、どちらも確認画面のまま止まっていた操作です。

フックの仕組み全般は、Claude Code hooksの使い方と実録で詳しく書いています。

許可待ちを再発させないコマンドの書かせ方

確認画面を減らす近道は、ルールを広げることより、AIに書かせるコマンドの形をそろえることでした。当社が今も守っている運用です。

• 1回に1コマンド：つないだ時点で照合が分かれ、どこか1つで外れます。| tail と | head だけは例外として許しています
• cd を使わず絶対パス：フォルダを移ってからの git は確認対象なので、最初から移らせません
• 変数代入をさせない：先頭に代入があるとallowルールが合わなくなります
• 複雑な処理はスクリプトにする：複数行の処理は、1行のコマンドに詰めず、Pythonのファイルに書かせてから python3 ファイル名 で動かします
• 拒否のログを許可リストの見直しに使う：拒否された操作が安全で必要なものなら、allowに足します。危ないものは足しません

現在、当社のユーザー設定は、allowルール50件・askルール3件・既定の許可モードは acceptEdits です（2026年10月4日に集計）。

許可を広げすぎないための注意（チーム・無人実行）

広げ方を間違えると、取り返しのつかない操作まで通ります。業務では次の点に気をつけてください。

Bash(*) で全部許可しない。 公式では、Bash と Bash(*) はどちらもすべてのBashコマンドに合います。必要なコマンドを1つずつ足すのが基本です。

ルールは「安全の壁」ではない。 公式の説明では、Bash(rm *) をdenyにしても、/bin/rm のようにパスで書いた形や bash -c の中には合いません。確実に止めたいなら、サンドボックスやPreToolUseのフックを組み合わせます。

CLAUDE.mdで許可は変わらない。 公式は、CLAUDE.mdの指示はClaudeが何をしようとするかに影響するだけで、Claude Codeが何を許すかは変えないと明記しています。

チームの設定はdenyが勝つ。 どの設定ファイルのdenyも、ほかのファイルのallowより先に評価されます。プロジェクトの .claude/settings.json のallowルールは、そのフォルダを信頼すると承認したときにだけ効きます。

無人実行は「拒否して進む」形にする。 公式には、確認が要る操作をすべて自動で拒否する dontAsk モードがあり、CIやスクリプト向けとされています。当社は、対話と無人で同じ設定を使うため、無人のときだけ拒否するフックを選びました。claude -p での無人実行は、claude -pの使い方と、定期タスクが止まった実録に書いています。

確認なしにしてよい操作と、人が押す操作を分ける。 当社の社内ルールでは、ファイル編集やWeb検索は確認なし、メールの送信やファイルの削除は確認ダイアログあり、広告の公開や支払いはツールの許可が通っても押す前にチャットで承認、の3段階に分けています。確認を減らすのは1段目だけです。