Claude Code「Don't Ask Again」で秘密情報が漏えい｜settings.local.jsonの確認・削除・予防策【2026年11月】

Claude Code で「Yes, and don't ask again（今後は確認しない）」を選ぶと、承認したコマンドが .claude/settings.local.json に許可ルールとして保存されます。コマンドにパスワードやトークンを直接書いていれば、それも一緒に残ります。Claude Code はこのファイルを git の対象から外しますが、外す設定は開発者のPCの側に書かれ、リポジトリには付いていきません。そのため、公開GitHubでは1,122ファイルから実際の秘密が見つかっています（セキュリティ企業 Apiiro、2026年11月5日公表）。

2026年11月8日時点の最新版 v2.1.319（11月6日公開）でも、保存されたルールから秘密を伏せる修正は CHANGELOG で確認できません。Anthropic の公式見解も出ていません。Claude Code を使っているリポジトリがあるなら、まず自分のリポジトリを確認してください。

この記事でわかること

• 「Yes, and don't ask again」を選んだとき、何がどこに保存されるのか
• Apiiro 調査の数字（1,122件と2,539件の違い、秘密の内訳、スキャナが見逃した215件）
• 「git から外れているはず」のファイルが漏れる7つの経路
• 5分でできる自己診断のコマンド
• 漏れていたときの対処の順番（なぜ履歴の削除より先に資格情報を無効化するのか）
• 個人・組織それぞれの予防策と、/permissions での削除手順

この記事の対象：Claude Code を業務や個人開発で使っているエンジニア、公開リポジトリや npm パッケージをメンテナンスしている人、社内で AI コーディングツールの導入・運用ルールを決める立場の人。

Claude Code の全体像は「Claude Codeとは？できること・料金・使い方」、権限・サンドボックスまで含むセキュリティ設定全般は「Claude Codeのセキュリティと危険性」で扱っています。

設定ファイルに残った秘密は「漏れたもの」として扱う

Claude Code そのものが秘密を外部に送ったわけではありません。 問題は、承認したコマンドの文字列がファイルに残り、そのファイルが git の除外をすり抜けて公開される経路があることです。

すぐに手を付けるのは次の3つです。

1. .claude/settings.local.json がコミットされていないか、履歴に残っていないかを確かめる（git ls-files と git log --all）
2. パスワード・トークン・接続文字列が入っていたら、その資格情報をすぐ無効化して再発行する。 ファイルの削除や履歴の書き換えはその後です
3. 今後は値の入ったコマンドをそのまま承認しない。 環境変数で値を渡し、承認はパターン（Bash(npm run *) など）で行う

コミットしていない場合でも、このファイルは平文のまま手元に残ります。PCのバックアップ、フォルダのコピー、zip での受け渡し、インフォスティーラー（情報窃取マルウェア）といった経路は残るので、中身の点検はしておいた方が安全です。

何が起きたのか：Apiiro 調査の要点

出典: Anthropic 公式サイト「Claude Code」製品ページ

Apiiro の研究者（Shmulik Cohen 氏・Matan Giladi 氏）が公開GitHub上の .claude/settings.local.json を調べたところ、約1.1%に実際の秘密が含まれていました。 データは2026年11月1〜3日に集め、影響を受けた組織には11月2〜3日に通知したうえで、11月5日に公表しています。Apiiro の原文は取得できなかったため、以下は複数の報道（Cyber Security News、GBHackers、iTWire など）で一致した数字です。

調査の規模と結果

報道によっては「1,122」と「2,539」が混ざって書かれていますが、数えている範囲が違います。1,122 は settings.local.json の現行ファイルの数、2,539 は履歴や会話ログまで含めた秘密の件数です。影響を受けた63組織は主にソフトウェア企業で、うち1社は露出したキーがまだ有効だったと確認しています。

一方で、Apiiro は資格情報が実際に使えるかどうかを網羅的には試していません。iTWire の報道でも「実際の侵害ではなく、露出のリスク」と位置づけられています。

何が漏れていたか

（GBHackers の内訳による）

3分の1を超える秘密が、データベースを直接開けるものでした。開発中に psql や mysql で接続を試し、そのコマンドを「今後は確認しない」で承認した、という流れが想像しやすい内容です。

シークレットスキャナでも見つからないものがある

見逃しの多くは PGPASSWORD=、sshpass -p、mysql -p の後ろや、リクエストヘッダーに入ったパスワードでした。AWS のキーのような決まった接頭辞が無いため、パターンに当たりません（両スキャナとも検証ステップは使わずに実行）。「スキャナを回しているから大丈夫」とは言えないのが、この件の厄介なところです。

他のエージェントとの違い

Apiiro は16のコーディングエージェントを比べ、承認したコマンド全体を既定でプロジェクト内のファイルに保存すると確認できたのは Claude Code だけだったとしています（比較した16ツールの名前は、今回確認できた報道には載っていません）。

なお、Claude と共著のコミットがこのファイルを変更していたのは、追跡できた1,105リポジトリのうち539でした。これは「Claude が秘密を書き込んだ」という証明ではありません。秘密を含むコマンドを打って承認したのは、ほとんどの場合は人間です。

「Yes, and don't ask again」は何をどこに保存するのか

出典: Claude Code 公式ドキュメント「Permission modes」

Bash コマンドと Web fetch の「don't ask again」は、リポジトリ単位で永続する許可ルールとして .claude/settings.local.json に書き込まれます。 ファイル編集の承認はセッションが終われば消えるので、同じ「don't ask again」でもツールによって残り方が違います。

許可プロンプトの選択肢

Manual モード（設定値は default）で Claude Code がコマンドを実行しようとすると、公式ドキュメントの例では次の4つの選択肢が出ます。

• Yes
• Yes, and don't ask again for: npm test *
• Yes, and switch to auto mode
• No

CLI は英語表示です。この記事では「今後は確認しない」と訳して書きますが、日本語UIでの正式な表記は確認できていません。

ツールごとの承認の残り方

（公式ドキュメント「Permissions」による）

秘密が残るしくみ

保存されるのは、承認した選択肢に表示された範囲の文字列です。公式の例のように npm test * という形の選択肢が出れば、値は残りません。ところが、PGPASSWORD=hunter2 psql -h db.example.com -U admin のような値入りのコマンドを、その形のまま「今後は確認しない」で承認すると、パスワードごと allow ルールになります。

{
  "permissions": {
    "allow": [
      "Bash(PGPASSWORD=hunter2 psql -h db.example.com -U admin -c \"select 1\")"
    ]
  }
}

（例示用の架空の値です）

どの形で選択肢が出るかはコマンドの形によって変わり、接頭辞の候補を出せない場合は一度きりの承認しか選べないこともあります。GitHub の issue #5544（2025年8月起票）と Apiiro の調査は、コマンド全体がそのまま保存されたケースを報告しています。issue #5544 は2026年1月に「60日間動きが無い」として bot が自動でクローズしたもので、修正されたわけではありません。

git status && npm test のような複合コマンドを承認したときは、承認が必要なサブコマンドごとに別々のルールが保存されます（1回で最大5件）。

名前が似ている「dontAsk モード」は別の機能

権限モードの1つ dontAsk は、確認が必要になる呼び出しをすべて自動で拒否するモードで、CI などで許可したものだけを実行させるために使います。「Don't ask again（今後は確認しない＝許可を保存する）」とは逆の働きです。権限モードの違いは「Claude Code Auto Mode とは」でも整理しています。

settings.local.json が「git から外れているはず」なのに漏れる理由

出典: Claude Code 公式ドキュメント「Settings」

Claude Code はこのファイルを、リポジトリの .gitignore ではなく、その PC 全体に効く「グローバルの git 除外ファイル」で外しています。 除外の設定がリポジトリと一緒に動かないので、別の PC や CI、別のツールでコミットすると、このファイルは除外されません。

settings ファイルの種類

優先順位は高い順に Managed → コマンドライン（--settings）→ Project local → Shared project → User です。permissions.allow のようなリストは上書きではなく、スコープをまたいで合算されます。

除外の書き込み先

公式ドキュメントによると、Claude Code が git リポジトリの中で初めてこのファイルを書くとき、まだ無視されていなければ **/.claude/settings.local.json をグローバルの git 除外ファイルに追加します。追加先は次のとおりです。

1. core.excludesFile が設定されていれば、そのファイル（絶対パスか ~ 始まりの場合）
2. 無ければ $XDG_CONFIG_HOME/git/ignore
3. それも未設定なら ~/.config/git/ignore

公式は「ファイルを手で作った場合は、自分で .gitignore に追加して」とも書いています。一方で、承認したコマンドに秘密が入る危険を名指しした注意書きは、2026年11月8日時点の公式ドキュメントでは見当たりませんでした。

除外が効かない7つの経路

⑥ については、Check Point が2026年4月に npm パッケージ約46,500件を調べ、428件に .claude/settings.local.json が含まれ、そのうち33ファイル（30パッケージ）に npm トークン・GitHub の個人アクセストークン・Bearer トークンなどの資格情報があったと報告しています（IT Brief UK、2026年4月23日）。公開済みの tarball は非推奨にしても取得できるため、漏えいしたものとして扱う必要があります。

Anthropic 自身も、v2.1.307（2026年10月21日）で「--use-anthropic-git-proxy を使うセッションが、前のセッションがクローンに残した .claude/settings.local.json をコミットしてしまう問題」を修正しています。このファイルが誤ってコミットされる経路は、実際にあるということです。

保存場所の例外

次の場合は、リポジトリのルートではなく .claude/settings.json と同じ場所に保存されます。

• git リポジトリの外で使っている
• リポジトリのルートがホームディレクトリになっている
• Windows で使っている
• フォルダの所有者が自分ではない

ホームディレクトリそのものを git 管理している人（dotfiles など）は、とくに注意してください。

なお、ファイルが git で追跡されている場合や .claude がシンボリックリンクになっている場合、Claude Code はこのファイルをリポジトリ由来として扱い、ワークスペースを信頼するまで allow ルールを保留します。追跡されていない場合は、信頼の手順なしで適用されます。クラウドセッション（claude.ai/code）ではこのファイルは読まれません。

5分でできる自己診断

確かめるのは「追跡されているか」「過去にコミットされたか」「どの設定で除外されているか」「中に秘密があるか」の4点です。 リポジトリのルートで順に実行してください。

① 今、追跡されていないか

git ls-files | grep 'settings.local.json'

何か表示されたら追跡されています。古いバージョンの Claude Code で起動したサブディレクトリに作られたファイルも、この方法なら拾えます。

② 過去にコミットされていないか

git log --all --oneline -- '*settings.local.json'

コミットが1つでも表示されたら、今のファイルを消しても履歴には残っています。

③ どの設定で除外されているか

git check-ignore -v .claude/settings.local.json

出力の先頭に、どのファイルの何行目のルールで無視されているかが出ます。

グローバル除外だけで外れている場合は、リポジトリの .gitignore にも追加しておくべきです。

④ 中に秘密が入っていないか

Claude Code のセッション内で /permissions を開くと、すべてのルールと、それぞれがどの settings ファイル由来かが一覧で出ます。次のような文字列を含むルールが無いか見てください。

• PGPASSWORD=、MYSQL_PWD=、mysql -p、sshpass -p
• Authorization:、Bearer 、-H "X-Api-Key: ...
• postgres://user:pass@... のような接続文字列
• ghp_、glpat-、npm_、sk-、AKIA などで始まるトークン

履歴まで含めて探すなら、次のコマンドが手がかりになります。

git log --all -p -- .claude/ | grep -nE 'PGPASSWORD=|MYSQL_PWD=|sshpass -p|mysql .*-p|Authorization:|Bearer '

共有用の .claude/settings.json も同じように確認してください。Apiiro の調査では、こちらにも298件の秘密がありました。会話ログ（transcript）やメモリファイルをリポジトリに入れている場合は、それらも対象です。

秘密が漏れていたときの対処：順番が大事

出典: GitHub Docs「Removing sensitive data from a repository」

最初にやるのは資格情報の無効化と再発行です。ファイルの削除や履歴の書き換えはその後にします。 公開された時点で、その秘密は誰かに取得されたものと考えるべきです。履歴を書き換えても、すでに作られた fork やクローン、キャッシュには届きません。

④ 追跡を外して .gitignore に追加する

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore
git commit -m "Stop tracking Claude Code local settings"

git rm --cached は手元のファイルを残したまま、追跡だけを外します。.gitignore に書いただけでは、すでに追跡しているファイルは外れません。

⑤ 履歴を書き換える場合の注意

履歴からファイルを消すには、git filter-repo などのツールを使います（例: git filter-repo --path .claude/settings.local.json --invert-paths）。ただし、書き換えると全員のクローンと履歴が食い違い、force push も必要になります。チームで使っているリポジトリなら、事前に周知してから行ってください。

GitHub 上のキャッシュされた表示や fork の扱いは GitHub 側の手続きになります。いずれにしても、①の無効化が済んでいれば、履歴に残った値は使えない文字列になります。

npm に公開してしまった場合

公開済みのバージョンは、非推奨にしても取得できる状態が続きます。資格情報を無効化したうえで、次のバージョンから .npmignore に .claude/ を追加し、公開前に npm pack --dry-run で同梱ファイルを確認してください。

予防策：個人でできること

根本の対策は「秘密の値をコマンドに直接書かない」ことです。 そのうえで、承認の仕方と除外の設定を見直します。

パターンで承認するときの注意

公式ドキュメントは、* をサブコマンドの後ろに置くよう注意しています。Bash(git *) と書くと、git push --force まで含めたすべての git コマンドを許可してしまいます。Bash(git status)、Bash(git diff *) のように、許可したい範囲だけに絞ってください。

deny ルールの例と限界

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

（公式ドキュメントの例）

Read の deny は、組み込みのファイルツールに加えて、cat・head・tail・sed・tee やリダイレクトにも効きます。一方で、grep -r pattern . のようにファイル名を書かないコマンドや、スクリプトの中でファイルを開く処理は止められません。.claudeignore は効果が無いと公式に書かれているので、deny ルールに移してください。

Bash の deny も書かれた文字列と照らし合わせるだけなので、/usr/bin/curl や sh -c 'curl …' は Bash(curl *) では止まりません。OS のレベルで止めたいならサンドボックスを使います。設定方法は「Claude Codeのセキュリティと危険性」にまとめています。

PreToolUse フックでコマンドを検査する

承認の前に、コマンドに PGPASSWORD= の後ろに値が直接書かれていないか、sshpass -p が使われていないかを調べ、当てはまったら止めるフックを置く方法もあります。フックは Claude Code が決まった処理として実行するので、Claude の判断に左右されません。書き方は「Claude Code Hooksの使い方」、Skills との役割分担は「Claude Code SkillsとHooksの違い」を参照してください。

予防策：組織でできること

出典: Claude Code 公式ドキュメント「Configure permissions」

組織としては、managed settings で「今後は確認しない」による保存そのものを止めるのが確実です。 公式の allowManagedPermissionRulesOnly を有効にすると、ユーザー・プロジェクト・ローカル・--settings の許可ルールが無視され、許可プロンプトの「常に許可」の選択肢が隠れ、新しいルールも保存されなくなります。

managed settings の配布方法（管理コンソール、MDM、ファイル配置）と、Team / Enterprise の管理機能の範囲は「Claude Codeのチーム導入ガイド」で扱っています。allowManagedPermissionRulesOnly がどの契約プランで使えるかは今回確認できていないので、導入前に公式の案内か管理コンソールで確かめてください。

v2.1.319（2026年11月6日）では permissions.denyInsteadOfPrompting も追加されました。承認待ちになるツール呼び出しを拒否してターンを続ける設定で、この件の直接の対策ではありませんが、無人実行でプロンプトに頼らない運用を組むときの選択肢になります。

Claude Code で作った試作やツールを社内の実データや既存システムにつなぐ段階では、DB の接続情報や API キーを誰がどこに持ち、どう渡すかを最初に設計し直す必要があります。開発者の手元で動いた構成をそのまま業務に持ち込むと、今回のような平文の資格情報も一緒に残りがちです。本番運用に移すときの確認ポイントは「バイブコーディング・Lovableで作ったアプリを本番運用するには」で整理しています。

公式の対応状況（2026年11月8日時点）

Anthropic からの公式見解と修正予定は確認できていません。 報道各社の記事にも Anthropic のコメントは載っていません。

一部に「2.0.54 で修正された」とする記述がありますが、出典元自身が検証できていないとしており、この記事では採用していません。修正が出た場合は、この記事にも反映します。

公式ドキュメントにある次の一文は、この件を考えるうえでも大事です。「パーミッションルールはモデルではなく Claude Code が強制する。プロンプトや CLAUDE.md の指示は許可範囲を変えない」。CLAUDE.md に「秘密をコマンドに書かないで」と書くのは悪くありませんが、それだけでは防げません。

同じ「確認を減らす」機能のリスクとしては、「Claude Code Auto Mode が間接プロンプトインジェクションで突破された件」もあわせて読むと、承認を省く設計の弱点がつかみやすくなります。Claude Code まわりの別の漏えい事案は「Claude Code ソースコード流出まとめ」で扱っています。

「今後は確認しない」を使ってよい人・やめた方がよい人

「今後は確認しない」自体は便利な機能で、値の入らないコマンドに使う分には問題ありません。 危ないのは、資格情報を手で打つ作業と組み合わせたときです。

使っても問題が起きにくい人

• npm test・npm run lint・git status のように、値が入らないコマンドだけを承認している人
• 資格情報を環境変数やシークレットマネージャーから渡す運用がすでにできている人
• リポジトリの .gitignore に .claude/settings.local.json を入れ、定期的に /permissions を見直している人
• Auto mode やサンドボックスで確認の手間を減らし、許可ルールをほとんど溜めない使い方をしている人

やめた方がよい人・使い方

• psql・mysql・ssh・curl にパスワードやトークンを直接書いて試している人：承認するたびに値が残る
• 公開リポジトリや OSS をメンテナンスしている人：除外が外れた時点で全世界へ公開される
• 複数の PC や CI、別の git クライアントで同じリポジトリを触る人：グローバル除外がどこかで効かない
• npm などにパッケージを公開している人：.claude/ が同梱されても既定では止まらない
• 本番 DB や root 権限の SSH をローカルから直接触る人：漏れたときの被害が大きい
• dotfiles などでホームディレクトリを git 管理している人：保存場所が想定と変わる

AI エージェント全般で資格情報をどう扱うかは「AIエージェントのセキュリティ対策ガイド」でまとめています。

よくある質問

Q1. 「Yes」を選んだだけでもファイルに保存されますか？

いいえ。「Yes」は一度きりの承認で、ファイルには書き込まれません。保存されるのは「Yes, and don't ask again」のように継続して許可する選択肢を選んだときです。.claude/settings.local.json は、この継続的な承認を初めてしたときに作られます。

Q2. Claude Code が勝手に秘密をコマンドに入れることはありますか？

あり得ます。GitHub の issue #25053 では、認証エラーが起きたときに Claude が資格情報を探して curl のコマンドに入れた事例（#9637）が挙げられています。そのコマンドを中身を見ずに「今後は確認しない」で承認すると、値ごと保存されます。.env などの読み取りを deny ルールで禁止し、承認の前にコマンドの中身を確認してください。

Q3. 非公開リポジトリなら気にしなくてよいですか？

外部に公開されるリスクは下がりますが、なくなりはしません。リポジトリを見られる社員や委託先、連携している CI・外部サービスのすべてが読めます。将来リポジトリを公開する、fork を許可する、退職者のクローンが残る、といった経路もあります。秘密が入っていたら、非公開でも無効化と再発行をおすすめします。

Q4. 承認したルールを一括で消したいときはどうすればよいですか？

/permissions で1件ずつ削除できます。ファイル自体を削除すると、そのリポジトリで保存したすべての許可ルールが消えます。次に同じコマンドを実行したときにもう一度確認が出るだけなので、中身を整理しきれないなら、資格情報を無効化してからファイルを消して作り直すのも現実的です。

Q5. WebFetch の「don't ask again」にも危険はありますか？

WebFetch はドメイン単位で保存されるので、パスワードが入る心配は Bash より小さいです。ただし、URL のクエリにトークンを付けて取得するような使い方をすると、保存されるルールの形によっては残る可能性があります。社内システムの URL やドメインが分かるだけでも、外に出したくない情報になることがあります。

Q6. Gitleaks や TruffleHog を CI に入れていれば十分ですか？

十分ではありません。Apiiro の調査では、1,122件のうち215件をどちらのツールも見逃しました。PGPASSWORD= や sshpass -p の後ろにある、決まった形を持たないパスワードがパターンに当たらないためです。既定のルールに加えて、こうした書き方を検出する独自ルールを足すか、コマンドに値を書かない運用で、秘密がファイルに入らないようにする方が確実です。

まとめ：今日やることのチェックリスト

「Yes, and don't ask again」で保存されるのは承認したコマンドの文字列で、値を書いていれば秘密も残ります。 Claude Code の除外は PC 側の設定なので、それだけに頼らないことが大切です。

• git ls-files | grep 'settings.local.json' で追跡されていないか確認する
• git log --all -- '*settings.local.json' で過去のコミットを確認する
• git check-ignore -v で、除外がグローバル設定だけに頼っていないか確認する
• /permissions で、パスワード・トークン・接続文字列を含むルールが無いか確認する
• 秘密が見つかったら、ファイルや履歴を消す前に資格情報を無効化して再発行する
• リポジトリの .gitignore に .claude/settings.local.json を追加する
• 資格情報は環境変数かシークレットマネージャーで渡すようにする
• npm に公開するパッケージは .npmignore に .claude/ を入れ、npm pack --dry-run で確認する
• 組織では allowManagedPermissionRulesOnly や deny ルールの配布、CI での独自スキャンを検討する

2026年11月8日時点では、Claude Code の側で秘密を伏せる修正は出ていません。修正が出るまでは、承認する前にコマンドの中身を見る習慣と、値をコマンドに書かない運用で守るのが現実的です。

関連記事

• Claude Codeとは？できること・料金・使い方
• Claude Codeのセキュリティと危険性
• Claude Code Hooksの使い方
• Claude Code SkillsとHooksの違い
• Claude Code Auto Mode とは
• Claude Code Auto Mode が間接プロンプトインジェクションで突破された件
• Claude Codeのチーム導入ガイド
• AIエージェントのセキュリティ対策ガイド