ダウンロードフォルダでClaude Code・Codexを起動しない 置かれた指示書で乗っ取られる
「ダウンロードフォルダでClaude CodeやCodexを起動してはいけない」。そんな投稿がXで広がっています。元になったのは、セキュリティ企業Forever Securityが10月22日に公開した報告です。ダウンロードフォルダに置かれたMarkdownのファイルに、AIのコーディングエージェントが従ってしまう。その悪意あるファイルが、実際の顧客のパソコンで見つかったといいます。
今回報告された入口を避ける基本は、ダウンロードフォルダ(~/Downloads)でエージェントを起動しないことです。ただ、それだけで安心できるわけではありません。すでに設定を書き換えられていれば、起動する場所を変えても残りますし、同じ形の罠はほかのフォルダにも入りえます。なぜDownloadsが狙われたのかを知っておくと、そうした別の罠にも気づきやすくなります。
ブラウザが勝手に保存したAGENTS.mdに、エージェントが従ってしまう
始まりは、ある顧客のパソコンでの警告でした。AIのコーディングエージェントが、作業の途中で、既知の悪意あるnpmのパッケージ(function-color)を入れようとしていた。Foreverの製品がそれを止めたあと、指示の出どころを調べると、ダウンロードフォルダに置かれた AGENTS.md というファイルにたどり着いた、という経緯です。中身は、ふつうの開発メモに見せかけてありました。誰がどうやって置いたのかは、わからなかったとされています。
AGENTS.md は、Codexなどのエージェントに「このプロジェクトではこう動いて」と伝えるための指示書です。Claude Codeでは CLAUDE.md が同じ役割を持ちます。エージェントは、起動したフォルダにあるこうした指示書を最初に読み込み、従います。自分たちで中身を確かめ、管理している指示書なら、それは意図した使い方です。
問題は、ダウンロードフォルダには、外から来たファイルが直接入ってくることです。ブラウザの多くは、ここを既定の保存先にしています。Webページは、ブラウザの設定によっては、確認なしにファイルを保存させることができ、名前も中身もページの側で決められます。一方で、ただの文書ファイルが1つ保存されても、それ自体が勝手に動くことはありません。だから害はない、というのがこれまでの考え方でした。
この2つが重なると、話が変わります。
- Webページは、ダウンロードフォルダに
AGENTS.mdやCLAUDE.mdという名前の文書を置ける - エージェントは、起動したフォルダの指示書を、指示として読み込む
つまり、ダウンロードフォルダでCodexやClaude Codeを起動すると、どこかのWebサイトが置いた文書が、エージェントへの指示として読み込まれます。そこから設定の書き換えや通信、プログラムの実行まで進むかは、エージェントの設定や承認しだいですが、Foreverは実際にそこまで進む例を再現しています。同社はこれを「Markdownが新しい実行ファイルになった」と表現しています。ファイルを自分で開く必要もありません。最近は、エージェント自身にブラウザを使わせることも増えているので、人が画面を見ていない間に置かれることもありえます。
Codexは設定に居座り、Claude Codeはログインの鍵を抜かれる
Foreverは、Webからファイルをダウンロードフォルダに置くところから、CodexとClaude Codeで再現しています。被害の形は、2つでかなり違いました。
| Codex | Claude Code | |
|---|---|---|
| 使った指示書 | 顧客のパソコンで見つかった AGENTS.md そのもの | それを参考にForeverが作った CLAUDE.md |
| 起きたこと | 「プロジェクトのツール」と称する接続先をCodexの設定に足し、npmのパッケージを入れる | Claudeの通信先を、攻撃者のサーバーに向け直す |
| 被害 | 攻撃者のプログラムが動く。設定はそのユーザーのCodex全体で使われるので、どのフォルダで起動しても続く | ログインのトークンが漏れる。偽の応答でコマンドを実行させることもできる |
| 再現の成功率(Foreverの試験) | 9割超 | 約5割 |
成功率は、Foreverが自分たちの試験で出した数字です。試した回数や製品のバージョンは示されていないので、一般にこの確率で被害が出る、という意味ではありません。
Codexの側で厄介なのは、書き換えられるのが ~/.codex/config.toml という、そのユーザーのCodex全体で使われる設定ファイルだという点です。一度書かれると、ダウンロードフォルダから離れても、Codexを起動するたびに攻撃者の接続先が読み込まれます。
Claude Codeは、だまされにくかったと報告されています。それでも半分ほどは、通信先を書き換える指示に従ってしまった。通信先が攻撃者のサーバーになると、ログインのトークンが渡ります。トークンは合鍵のようなもので、プログラムを動かされなくても、アカウントを乗っ取られたのと同じことになります。
Foreverは、これはどちらかの製品の不具合ではないとしています。エージェントが起動したフォルダの指示書に従うのは、そう作られているからです。偽の銀行のページを表示したブラウザが、ページを表示するという仕事をしただけなのと同じで、OpenAIにもAnthropicにも直すべき箇所はない、という見立てです。同社の顧客の約半数が、ダウンロードフォルダの中でエージェントを動かしていたそうです。
確認画面はある。ただ、一度信頼したフォルダの中身が変わっても聞かれない
では、各社の製品には守る仕組みはないのか。ここまでがForeverの報告の内容で、ここから先は公式の文書で確かめた仕組みと、筆者の考えを分けて書きます。
Claude Codeの公式の説明によると、まだ信頼していないフォルダで起動すると、「このフォルダを信頼するか」の確認画面が出ます。ただし、その答えはフォルダごとに保存されます。一度ダウンロードフォルダを信頼してしまえば、あとから新しい CLAUDE.md が置かれても、もう聞かれません。また、コマンドから -p で一度だけ動かす使い方では、この確認自体が出ないとされています。
Codexの公式の説明では、Gitで管理していないフォルダで起動すると、読み取り専用のモードを勧めるとされています。作業フォルダの外のファイルを書き換えるときや、ネットにつなぐときには、承認を求める作りです。ただ、承認を切る --yolo のような使い方をしていれば、そこで止まることはありません。
Foreverの報告の技術的な詳細には、守りをどう抜けたかも書かれています。
- Codex: 指示書に従うのは、信頼したフォルダの中だけです。ただ、一度ダウンロードフォルダで作業していれば、そこは信頼済みになっています。指示書は、ネットにつなぐためと称して、承認とサンドボックスを外すオプション付きでCodexをもう一度起動させ、パッケージの取得はCodexの管理の外で動く仕組みに任せていました
- Claude Code:
.claude/settings.jsonへの書き込みには、人の承認が要ります。おかしな書き込みは断ることも多かったものの、長い開発メモに見せかけることで、約半数で書き込みまで進みました。書き込まれると、次に起動したとき、偽の応答が「サンドボックスを外してコマンドを実行する」よう指示してきます
試験したときの設定一式やバージョンは示されていませんが、どちらも、守りがないから破られたのではなく、守りを外すよう言葉で誘導された、という形です。そのうえで筆者は、「フォルダへの信頼はフォルダの単位、攻撃はファイルの単位」というずれが本質だと思っています。人が「このフォルダは大丈夫」と判断したあとで、中身だけが外から入れ替わる。フォルダを信頼するかの確認だけでは、あとから入ってくるファイルまでは保証できません。
だからこそ、操作ごとの承認とサンドボックスが、もう一枚の守りとして意味を持ちます。承認が必要な操作では、指示書がどこから来たかに関係なく、実行の前に人に聞いてきます。サンドボックスは、許した範囲の外への書き込みや通信を止めます。ただし、どちらもすべての操作を覆うわけではなく、許可した範囲の中の操作は確認なしで進みますし、人が「はい」と押せばそれまでです。設定ファイルを書き換える、通信先を変える、承認やサンドボックスを外す。この種の確認が出たら、一度手を止めて、なぜそれが必要なのかを考えるのが、いちばん効く守りだと思います。
すぐにできること。自分のパソコンも確かめた
Foreverの勧めと公式の文書をもとにすると、次のようになります。
- ダウンロードフォルダでClaude CodeやCodexを起動しない。ブラウザの保存先を別のフォルダに変えているなら、そのフォルダも同じです
- 作業はプロジェクトごとのフォルダで行う。ダウンロードしたファイルを使うときは、中身を見てから作業フォルダに移します
- 見覚えのない
AGENTS.mdやCLAUDE.mdがあれば、エージェントに触らせる前に自分で読む。クローンしたばかりのリポジトリや、人から受け取ったフォルダも同じです - エージェントの設定を確かめる。Codexの
~/.codex/config.tomlに覚えのない接続先([mcp_servers.○○])や通信先の書き換えがないか、Claude Codeの設定ファイル(ユーザー全体の~/.claude/settings.jsonと、各プロジェクトの.claude/settings.json)にANTHROPIC_BASE_URLのような、覚えのない通信先がないかを見ます - 承認とサンドボックスを切らない。指示書が「確認を省いて」と言ってきたら、それ自体を疑います
- 見つけたら、まず使うのを止める。不審な設定を取り除き、漏れたかもしれないログインの情報を無効にしてから作り直します。無効にする方法は、各社の案内で確かめてください
当社では、もともとダウンロードフォルダでClaude CodeやCodexを起動することはありません。それでも、念のため代表のパソコンで確かめてみました。Macのターミナルで使ったコマンドは次のとおりです。
ls -la ~/Downloads/AGENTS.md ~/Downloads/CLAUDE.md ~/Downloads/.claude
3つとも「No such file or directory」と出れば、今この3つは置かれていません。私たちのところも、3つともありませんでした。ただし、これは今の時点でこの場所にないことの確認で、過去に何かが起きなかったことや、ほかのフォルダまでを保証するものではありません。
grep -n "mcp_servers\|base_url" ~/.codex/config.toml
こちらは、Codexの設定の中で接続先や通信先が書かれている場所を探すコマンドです。見つかった行番号の前後を開いて、それぞれの設定のまとまりを読みます。私たちの環境では接続先が2つ見つかりました。設定の中の起動するプログラムの場所が、どちらも /Applications/ChatGPT.app の中と、Codexの画面操作の機能のアプリを指していて、公式のアプリが自分で足した設定だと判断しました。npmのパッケージを取りに行くような接続先や、通信先の書き換えはありません。Claude Code側の設定にも、通信先を変える記述はありませんでした。見覚えのない接続先があって、何を指しているか判断できないときは、そのまま使わずに詳しい人に見てもらうのが安全です。
最後に、仕事の種類ごとに、エージェントに渡す権限を分ける
今回の件でいちばん大きいのは、ダウンロードフォルダという特定のフォルダの話よりも、「人が何かしない限り、ファイルは悪さをしない」という前提が崩れたことだと思います。エージェントは、人の代わりに読み、判断し、動きます。しかも最近は、ブラウザまで自分で操作します。
私たちのブログ制作でも、Claude CodeとCodexを毎日使っています。ダウンロードフォルダで起動することはなく、作業はいつもプロジェクトごとのフォルダで行い、Codexに記事のレビューをさせるときは、ファイルを書き換えられない読み取り専用の設定で動かしています。レビューは読むだけの仕事なので、書き換える権限は要らないからです。
会社で使うなら、この「仕事の種類ごとに権限を分ける」考え方が使えると思います。文章のチェックや調べ物のような読むだけの仕事は、読み取り専用で動かす。実装のように書き換える仕事は、プロジェクトのフォルダの中だけで、承認を残して動かす。エージェントにブラウザを使わせる仕事は、ふだんの作業とは別のフォルダ、できれば別のマシンや仮想環境で動かす。そのうえで、エージェントを起動してよいフォルダを決め、ダウンロードフォルダやデスクトップのような、外から物が置かれる場所は外しておく。ここまで決めておけば、今回のような罠に出会っても、被害は小さく抑えられるはずです。