Claude Code「今後は聞かない」で秘密が公開repoに　自分のrepoの確かめ方

米Anthropicの「Claude Code」で、コマンドの確認に「Yes, and don't ask again」と答えると、そのコマンドが打ったパスワードごとプロジェクトの設定ファイルに残ることがある。The Hacker Newsが11月7日に報じたセキュリティ企業Apiiroの調査では、公開されたGitHubのrepoで計2539件の秘密が見つかった。Claude Codeで手早く作る個人や小さなチームほど、自分のrepoにこのファイルが入っていないかを今日のうちに確かめる価値がある。

承認の記録に秘密が残る

Claude Codeは、多くのシェルのコマンドを走らせる前に許可を求める。Claude Codeの設定の説明によると、ここで「Yes, and don't ask again」を選ぶと、その許可は「.claude/settings.local.json」にallowのルールとして保存される。以後は同じ形のコマンドを聞かずに実行する。

The Hacker Newsによると、保存されるルールは確認の画面が示した形のままだ。npm testのような型で残る時もあれば、1本のコマンドがそのまま残る時もある。後者で、コマンドの中にパスワードやトークンを直接書いていれば、それも平文で残る。研究者は最新のモデルでもこの動きを再現したという。

設定の説明では、このファイルは「この1つのプロジェクトで自分だけに効く設定」だ。Claude Codeはgitのrepoで初めてこのファイルを書く時、ユーザーの全体の除外の設定（グローバルのgit excludes）に1行足し、どのrepoでもコミットされないようにする。ただし自分で手作りしたファイルは対象外で、その時は自分で.gitignoreに足すよう説明は求めている。

守りはその1台にしか効かない

ところが、この除外はそのパソコンのgitの設定にしか残らない。研究者は、すでにコミット済みのファイルには効かず、Claude Codeはプロジェクト自身の.gitignoreには書かないと指摘した。別のパソコンで同じrepoを触れば守りは付いてこない。

Apiiroが公開のGitHubを探すと、このファイルの写しは10万4185個あり、うち1.1%にあたる1122個に秘密が少なくとも1つ入っていた。異なる秘密は1379件で、データベースのパスワードが379件、公開サーバーへのSSHのログインが43件、GitHub・GitLab・npmのトークンが42件、AWSの鍵が23件だった。チームで共有する.claude/settings.jsonや古い版、保存されたエージェントの会話の記録まで含めると、1994のrepoで2539件になる。

数字には限りもある。Apiiroは秘密が今も使えるかは試していない。ただ、知らせを受けた会社の1社は、鍵が有効だったと認めたという。また、追えた1105のrepoのうち539では、Claudeを共著者とするコミットがこのファイルを変えていた。

消しても履歴とフォークに残る

ファイルを消すだけでは足りない。古い版はgitの履歴とフォークに残るからだ。The Hacker Newsによると、今の写しには無く古い版にだけある秘密が、509のrepoで734件あった。74のrepoのフォーク211個も、元と同じ秘密を抱えていた。

よく使う検査の道具も見逃す。研究者がgitleaksとTruffleHogを全部の写しに掛けると、秘密入りの1122個のうちgitleaksが拾ったのは564個、TruffleHogは643個で、215個はどちらも拾えなかった。見逃しの多くは、PGPASSWORD=やsshpass -p、mysql -pの後ろに打ったパスワードだ。決まった鍵の形をしていないので、普通のコマンドの語に見えてしまう。

自分のrepoで確かめる手順

手元のrepoごとに、まず追跡の有無を見る。repoの一番上でgit ls-files .claudeを打ち、settings.local.jsonが出たらコミットされている。次にgit log --all --oneline -- .claude/settings.local.jsonで、今は消えていても過去に入ったことがないかを見る。チームで共有するsettings.jsonも同じように見る。

GitHubの組織を持つなら、コード検索でこの2つのファイル名を探し、repoごとに履歴も確かめるよう研究者は勧める。コミットしていなくても、手元のファイルは開いて読む。PGPASSWORD=、sshpass、mysql -p、password、tokenといった語のあるルールを探し、秘密の入ったルールは消す。

秘密が見つかったら、片付けより先にパスワードやトークン、鍵を全部取り替える。それからgit rm --cached .claude/settings.local.jsonで追跡をやめ、repo自身の.gitignoreにこのファイル名を足す。こうすれば守りがrepoと一緒に動く。

再発を防ぐには、秘密をコマンドに直接書かない。研究者は、$DB_URLのような環境変数で渡せば、保存されるルールには変数名しか残らないと説明する。あわせて、1本ずつではなくnpm runのような型で承認することを勧めた。研究者が比べた16のコーディングエージェントのうち、承認したコマンドの全文を既定でプロジェクトのファイルに残すと確かめられたのはClaude Codeだけだったという。承認の記録が秘密の置き場になる構図は、手元で確かめれば今日のうちに断てる。

編集部の見方

Claude Codeに任せてコミットまで進める作り方では、.claudeのフォルダも.envと同じく秘密を抱えうる場所として扱うのがよい。共著者の付いたコミットがこのファイルを変えていた例が多いという数字は、人が見ないうちにファイルが公開へ流れうることを示す。ただ、今回の数字はApiiroの調査であり、Anthropicの返答は報じられていない。設定の挙動が変わるかは、公式の説明の更新を見て判断したい。