Claude Codeの許可プロンプトで何が保存されるか — 「don't ask again」の中身

許可プロンプトの「Yes, and don't ask again」は、ツールの種類によって保存期間が変わります。Bashコマンドの承認は設定ファイルに残り続け、ファイル編集の承認はセッションが終わると消えます。同じ選択肢でも、押した結果は一様ではありません。

保存先は、gitリポジトリのルートにある .claude/settings.local.json です。ツール別の保存期間から入り、書き込まれるルールの形、保存先の決まり方、選択肢が出ない場面へ進みます。

「don't ask again」の保存期間はツールごとに違う

Claude CodeのManualモードでは、ツールの種類ごとに承認の要否と、この選択肢の効き方が決まっています。

「永続」と書かれた行だけが、設定ファイルへ書き込まれます。ファイル編集の承認は、同じ文言の選択肢でもファイルには残りません。

Bashの「Yes, and don't ask again」で書かれるルール

Bashコマンドのプロンプトには、「Yes」「Yes, and don't ask again for: ○○」「No」が並びます。公式の例では、npm test に対する2番目の選択肢が Yes, and don't ask again for: npm test * と表示されます。

選ぶと、コマンドの接頭辞に * を付けた形のルールが allow に追加されます。ダイアログが書くのは、スペースで区切った形です。例えば次のようなルールになります(公式のルール表記に沿った例です)。

{
  "permissions": {
    "allow": [
      "Bash(npm test *)"
    ]
  }
}

この * は、スペースを含む任意の文字列に一致します。末尾にスペース付きで置いた * は、引数なしの npm test にも一致します。一方、Bash(npm test *) が許可するのは npm test で始まるコマンドだけです。npm install は対象外で、プロンプトが残ります。

古い書き方の Bash(npm test:*) も、末尾に置く限り同じ意味で認識されます。ただし Bash(git:* push) のように途中へ置くと、コロンは文字として扱われ、gitコマンドには一致しません。

WebFetchとWebSearchで書かれるルール

WebFetchで「don't ask again」を選ぶと、ツール名にドメインを添えた形で allow に入ります。たとえば docs.example.com へのアクセスを承認すると、次のようなルールです(公式のルール表記に沿った例です)。

{
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.example.com)"
    ]
  }
}

domain: はURLのホスト名と照合され、大文字小文字は区別されません。*.example.com のように手書きでワイルドカードを使うと、サブドメインを深さを問わず一括で許可できます(example.com 自体は含みません)。ワイルドカードがfetchに効くのはv2.1.172以降です。

WebSearchにはドメインの概念がなく、永続の単位はリポジトリ全体です。保存されるのは、ツール名だけのルールです。

{
  "permissions": {
    "allow": [
      "WebSearch"
    ]
  }
}

ツール名だけのルールは、そのツールの呼び出しすべてに一致します。一度保存すると、そのリポジトリでは検索のたびの確認が出なくなります。

複合コマンドを承認すると、サブコマンドごとにルールが増える

git status && npm test のような複合コマンドを承認すると、全体を1本のルールにはしません。承認が必要だったサブコマンドごとに、別々のルールが保存されます。この例で保存されるのは npm test のルールです。以後は && の前に何が付いても、npm test は許可済みとして扱われます。

作業ディレクトリの外へ cd するサブコマンドは、そのパスに対するReadルールを別に生みます。1つの複合コマンドから保存されるルールは最大5件です。この上限と、サブコマンドの評価の仕組みはClaude CodeのBash権限ルールは複合コマンドをどう評価するかで扱っています。

ファイルパスの承認は記号をエスケープして保存される

ファイルパスへの承認を保存するとき、Claude Codeは [、]、* といったgitignore形式のパターン文字をエスケープします。生成されたルールが、承認したパスそのものにだけ一致するようにするためです。自分で書いたルールはエスケープされません。

v2.1.202より前は、パスをそのまま保存していました。[2024-06] Reports のようなディレクトリ名では、生成されたルールが自分のパスに一致しなかったり、隣のディレクトリまで巻き込んだりすることがありました。

保存先はgitリポジトリのルートに解決される

永続する承認は、現在のディレクトリではなく、gitリポジトリのルートにある .claude/settings.local.json に書かれます。サブディレクトリでClaude Codeを起動していても、保存先は変わりません。そのルールは、リポジトリ内のどこで始めた将来のセッションにも効きます。

worktreeではメインのチェックアウトに保存される

worktreeで承認した場合も、保存先はそのworktreeではなく、メインのチェックアウトの .claude/settings.local.json です。そのため、メインのチェックアウトと、同じリポジトリの他のworktreeすべてで有効になります。worktreeを削除しても、ルールは消えません。

ここで押さえたいのはバージョンの境目です。v2.1.211より前は、承認を起動したディレクトリに保存していました。worktreeで許可したルールは他の場所に効かず、worktreeの削除と一緒に失われました。それ以前のバージョンがサブディレクトリやworktreeに保存したルールは、そこで始めたセッションでは今も有効です。

ルートを使わない例外がある

gitリポジトリの外で起動した場合や、Windowsでは、Claude Codeはリポジトリルートを使いません。この場合は、設定の各ファイルがどこにあるかを一覧にした公式のsettingsの節「Where Claude Code looks for each file」に、保存先が載っています。リポジトリルートの .claude/settings.local.json とは別の場所になるため、ルールが効かないときはこの節で実際の保存先を確かめてください。worktreeでも、Windowsなどルートを使わない環境では、ルールはそのworktreeに残ります。

一回限りの承認しか選べないプロンプトがある

プロンプトによっては、「Yes」と「No」だけが出て、「don't ask again」もセッション内の許可も選べません。

これは不具合ではなく、設計上の挙動です。Claude Codeは、その選択肢が許可する内容をプロンプトにすべて表示できるときだけ、永続やセッション許可の選択肢を出します。保存されたルールが、プロンプトで見せた内容の範囲だけをカバーするようにするためです。

一回限りしか出ないときの手は2つあります。

• その場で一度だけ承認する
• /permissions を開き、ルールを自分で書き足す

/permissions には、全ルールと、そのルールがどの設定ファイルに由来するかが並びます。開くのはClaudeが作業中でも構いません。ルールの追加や削除は、同じターンの次のツール呼び出しから反映されます。

選択肢ごとに何が残るかの早見表

プロンプトに並ぶ選択肢を、残るものの観点で並べ直します。

「Yes, and switch to auto mode」は、全部のプロンプトに出る選択肢ではありません。ManualモードかacceptEditsのモードで、auto modeが使える状態のBashコマンドのプロンプトに追加されます。PowerShellツールのプロンプトには出ません。承認とモード切り替えが一度にできるだけで、永続ルールとは別物です。選択肢が出るのはv2.1.247以降で、自分の ask ルールやフックが起こしたプロンプトにも出ません。auto modeに切り替えても、そうしたプロンプトは消えないためです。

注釈を付けるとルールは保存されない

プロンプトで Yes や No の位置に合わせて Tab を押すと、Claudeへのコメント欄が開きます。ただし、セッション許可や保存ルールを作る選択肢には、このコメント欄がありません。コメントを添えて承認したいときは、普通の「Yes」を選びます。

保存したルールを後から確かめる・戻す

保存された承認は、ファイルを開くか、/permissions のダイアログで確認できます。ダイアログでは、ルールごとにどの設定ファイルから来たかが分かります。

ルールの評価順は、deny、ask、allowです。保存された allow ルールがあっても、同じコマンドに一致する deny や ask のルールが先に効きます。広い ask ルールを置いた場合、後から許可を保存しても、その確認は消えません。

ファイルがgitで追跡されている場合、または .claude がシンボリックリンクの場合、Claude Codeはそのファイルをリポジトリ由来のものとして扱います。この場合、フォルダを信頼するまでルールは保留されます。追跡されていない個人用のファイルなら、信頼ダイアログを待たずに allow ルールが適用されます。ファイルがgitの管理から外れる仕組みは、settings.local.jsonがgitignoreなしで除外される仕組みに詳しくあります。

承認を積み重ねてルールが増えたときの整理には、/fewer-permission-promptsで許可プロンプトを自動整理するが使えます。ルールに載っていない操作を一律で断る運用は、dontAskモードの領分です。

まとめ

永続するのは、Bashコマンド、WebFetchのドメイン、WebSearchの承認です。保存先はリポジトリルートの .claude/settings.local.json で、worktreeでもメインのチェックアウトに解決されます。

ファイル編集の承認は、同じ文言の選択肢でもセッション終了で消えます。「don't ask again」が出ないプロンプトでは、一度だけ承認するか、/permissions で自分でルールを書く方法が残ります。