Claude Codeのsettings.local.jsonにパスワードは残る？「次回から確認しない」を18形式で実測

「次回から確認しない」を押すと何が保存されるのか？

保存されるのは、承認したコマンドに対応する許可ルールです。置き場所はリポジトリ直下の .claude/settings.local.json で、中身は平文のJSONです。ルールがコマンドの一部をそのまま写すとき、コマンドに書かれたパスワードも一緒に保存されます。

公式ドキュメントによれば、Bashコマンドの承認で「Yes, and don't ask again」を選ぶと、そのルールは以後のセッションでもリポジトリ全体に効きます。作業を進めるうちに、データベースへの接続やAPIの呼び出しのたびに承認を重ねると、ファイルには承認の履歴が積み上がります。

Apiiroの調査は、この積み上がったファイルが公開リポジトリに入っている実態を数えたものです。2026年11月1〜3日に公開GitHubを検索し、次の数字を出しています。

スキャナーが見逃しやすいのは、PGPASSWORD= や mysql -p の後ろに書いた普通の単語のパスワードだとApiiroは指摘しています。HNでは、Claude CodeチームのBoris Cherny氏が次のように答えました。

「Claude Codeはこれまで秘密情報の除去をしてきませんでした（そのための良いツールは多くあります）が、防ぐためにできることを検討しています」

"Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this."

Boris Cherny（Claude Codeチーム）— Hacker News、2026年11月7日

同氏は、このファイルはClaude Codeが作るときに自動でgitから外すので、公開されていたのは手で作られてコミットされたものだ、とも書いています。一方Apiiroは、除外が入るのは利用者のグローバル設定だけで、リポジトリの .gitignore には入らないと反論しています。この食い違いは、次の2つの節で実測して確かめます。

パスワードが残るのはどんなコマンドのときか？

単独のコマンドなら、Claude Codeはルールを curl * や mysql * のようなコマンド名単位に一般化するため、パスワードは残りませんでした。残ったのは、先頭に環境変数を付けた形と、パイプや cd && を含む複合コマンドです。18形式中7形式で、パスワードがルールにそのまま入りました。

差が出る理由は、ダイアログの選択肢の文面で見分けられます。単独コマンドでは「Yes, and don't ask again for: mysql *」と表示されます。パイプ付きでは「for: mysql -h 127.0.0.1 -P 9 -u app -p（パスワード）…」と、パスワードが選択肢の中に見えていました。公式ドキュメントにも、複合コマンドはサブコマンドごとにルールを保存するとあり、その際の一般化が単独のときと違うようです。

この結果は、Apiiroの「承認したコマンドがそのまま保存される」という説明より狭い範囲です。ただし、AIが出力を短くするために付ける 2>&1 | head や、接続情報を環境変数で渡す書き方は日常的に出てきます。押す前に選択肢の文面にパスワードが見えていないかを確かめるのが、一番手前の防御です。見えていたら「Yes」（1回だけ許可）を選び、必要なら /permissions で Bash(mysql *) のようなルールを自分で足します。

settings.local.jsonはgitignoreされるのか？

gitリポジトリの中でClaude Codeが初めてこのファイルを書くときは、gitから外されました。手元の実測では毎回、グローバル除外ファイルに **/.claude/settings.local.json が追加され、git add -A しても登録されませんでした。ただし次の3つの条件では除外が効かず、パスワード入りのファイルがコミット対象になりました。

公式の設定のドキュメントも、除外を足すのは「gitリポジトリの中で初めて書くとき」と書き、手で作ったファイルは自分で .gitignore に足すよう求めています。つまりBoris氏の説明もApiiroの説明も、それぞれ一部が正しいことになります。除外は自動で入りますが、利用者のマシンの設定であり、リポジトリには何も残りません。

実務でありがちなのは、試作用のフォルダでClaude Codeを使い始め、あとからgit管理に切り替える場合です。当研究所のMacでも、~/development 配下の settings.local.json 81個のうち26個はgit管理外のフォルダにありました。Windowsでは置き場所の規則が変わると公式に書かれていますが、今回は試していません。

Claude自身がこのファイルをコミットすることはあるか？

あります。ただし条件はかなり限られました。未追跡のファイルは30回中1回もコミットされませんでした。すでに追跡されているファイルの変更を「全部まとめてコミットして」と頼んだときだけ、Sonnet 5.5が5回中4回コミットに含めました。

コミットしなかった回の多くは、「ローカル設定なので含めなかった」「パスワードが平文で入っている」と理由を添えていました。Sonnetが含めた4回のうち3回は事後にパスワードの存在を伝えましたが、1回は「設定を更新しました」とだけ報告しています。「全部」という依頼は、モデルにとって除外の判断を外す合図になり得ます。

Apiiroが数えた「Claudeが共同作成者のコミット」539件には、今回より古いモデルや、ファイルを追跡済みのリポジトリが多く含まれているはずです。今回の結果は単発の短い依頼であり、長い作業の途中のコミットは再現していません。

自分の環境に残っていないか確かめる方法は？

手元のファイルの許可リストを読み、パスワードらしいルールがないか、そのファイルがgitに追跡されていないかを見ます。次のスクリプトは、指定したフォルダ以下の .claude/settings*.json を探し、疑わしいルールの件数と追跡の有無を表示します。一致した部分は先頭6文字だけ残して伏せます。

import json, re, sys, pathlib, subprocess

PAT = re.compile(r"""(PASS|PASSWORD|TOKEN|SECRET|KEY|_URL)[A-Z0-9_]*=['"]?[^\s$'"]{6,}"""
                 r"""|://[^/\s:@$]+:[^/\s@$]{4,}@|sshpass -p\s*[^\s$]{4,}|\s-p[^\s$)]{4,}"""
                 r"""|Bearer\s+[A-Za-z0-9._-]{12,}|sk-[A-Za-z0-9_-]{16,}|ghp_[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}""")
root = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else ".").expanduser()
for f in root.rglob(".claude/settings*.json"):
    if "node_modules" in f.parts:
        continue
    try:
        allow = json.loads(f.read_text()).get("permissions", {}).get("allow", [])
    except Exception:
        continue
    hits = [r for r in allow if PAT.search(r)]
    if not hits:
        continue
    top = subprocess.run(["git", "-C", str(f.parent), "rev-parse", "--show-toplevel"],
                         capture_output=True, text=True).stdout.strip()
    tracked = bool(top) and subprocess.run(["git", "-C", top, "ls-files", "--error-unmatch", str(f)],
                                           capture_output=True).returncode == 0
    print(f"{f}  疑わしいルール {len(hits)} 件  git追跡: {'あり' if tracked else 'なし'}")
    for r in hits:
        print("   ", PAT.sub(lambda m: m.group(0)[:6] + "…", r)[:120])

判定は正規表現による目安で、取りこぼしも誤検知もあります。settings.json（チームで共有する方）も対象にしているのは、Apiiroがそちらでも298件の秘密を見つけているためです。すでにコミットしたことがあるかは、リポジトリで git log --all --oneline -- .claude/settings.local.json を実行すると分かります。履歴に残っていれば、いまファイルを消しても複製やフォークには残ります。

当研究所の ~/development で同じ確認をすると、81ファイル・2,762ルールのうち、パスワードらしいものはプレースホルダーに見える1件だけでした。追跡されていたファイルは2個で、どちらも非公開リポジトリで秘密らしいルールはありませんでした。

パスワードを残さないためには何をすればよいのか？

最も効くのは、パスワードをコマンドに書かせないことです。次に、リポジトリ側で .claude/settings.local.json を除外し、最後にスキャンで拾います。漏れていた場合は、ファイルを消すより先にパスワードを変更します。

#!/bin/sh
if git diff --cached --name-only | grep -q '\.claude/settings\.local\.json$'; then
  echo "settings.local.json はコミットしないでください（git rm --cached で外せます）" >&2
  exit 1
fi

Boris氏は、許可ルールを手で育てるよりautoモードを使うよう勧めています。autoモードで同じ8形式を実行すると、確認なしで実行され、settings.local.json は作られませんでした。ルールが書かれないので、この経路は閉じます。ただし、パスワード入りのコマンドを危険として止めたわけではありません。コマンドそのものは会話ログ（~/.claude/projects）に残ります。Anthropicのautoモードの解説は、1,053人の実験で人の確認が危険なコマンドの13.6%しか止めず、autoモードは89%を止めたと報告しています。autoモードの考え方はClaude Codeのautoモードの解説、権限設定全般はセキュリティチェックリストにまとめています。

同じ問題は2025年8月のissue #5544でも報告されていましたが、対応されないまま自動で閉じられています。Boris氏は11月7日、autoモードでの検出や基本的な秘密情報のスキャンなどを試作して比べると書きました。2026年11月8日時点の最新版v2.1.319には、まだ入っていません。

まとめ