新しいディレクトリでClaude Codeを立ち上げて、いきなり権限確認が出る。「Yes, and don’t ask again for this session」ではなく、ちゃんと「always allow」的な選択肢を選んだはずなのに、次にClaude Codeを起動したらまた同じ確認が出てくる。私も1年目の頃、これで「あれ、さっき許可しましたよね」と独り言を言いながら同じチェックを何度も押した記憶があります。既存の長く使っているプロジェクトでは起きないのに、作ったばかりの新規プロジェクトでだけ再現する。地味ですが、地味だからこそハマる人が多い罠だと思います。
結論から言うと、これはあなたの操作ミスではなく既知の不具合でした。公式changelogのv2.1.252（2026年8月31日）に、そのものずばりの修正エントリがあります。
Fixed "always allow" not saving in a project that has no .claude/settings.local.json yet「まだ.claude/settings.local.jsonを持っていないプロジェクトで、always allowが保存されない不具合を修正」。これを見たとき「ああ、あれ私のせいじゃなかったんだ」と少し安心しました。
実際に起きていた画面のイメージ
言葉だけだとピンとこないと思うので、実際に起きていたやり取りを再現してみます。新規プロジェクトでClaude Codeにコマンド実行を頼むと、こんな確認が出ます。
Bash command
npm install
Do you want to proceed?
1. Yes
2. Yes, and don't ask again for npm install commands in this project (always allow)
3. No, and tell Claude what to do differentlyここで2番を選べば「このプロジェクトでは今後npm installを聞かれなくなる」はずです。ところが不具合を踏んでいるバージョンでは、次にClaude Codeを起動して同じnpm installを実行すると、また同じ確認が出てきます。1回だけならまだしも、起動するたびに毎回同じ確認が出るとなると、さすがに「あれ、さっき2番押しましたよね」と言いたくなります。後述のGitHub issueでも、同じように「毎回選択しているのに保存されない」という報告が上がっていました。うっかり自分の操作ミスだと思い込んで見過ごしてしまいそうな、地味だけれど厄介な種類の不具合だったと思います。
再現条件: 新規プロジェクトだけで起きる
この不具合の一番わかりにくいところは、いつも起きるわけではないという点です。私が理解した範囲では、条件はこうです。
再現する: プロジェクト直下に .claude/settings.local.json がまだ存在しない
再現しない: すでに .claude/settings.local.json があり、追記するだけでよいつまり保存先のファイル自体がまだ無い、完全な初回のプロジェクトでだけ起きます。一度でも別の許可を保存したことがあるプロジェクトならsettings.local.jsonがすでに存在するので、そこへの追記は普通に成功します。既存プロジェクトでは全く再現しないのに、新規プロジェクトでは毎回起きる。これでは「自分の環境がおかしいのでは」と疑いたくなるのも無理はありません。
何が起きていたのか（正直に、わかる範囲で）
公式changelogの一文は「直った」という事実しか書いておらず、内部でどう壊れていたかまでは説明していません。ここから先は私の推測です。always allowを選ぶと、Claude Codeは許可内容を.claude/settings.local.jsonに書き込もうとします。ですがこのファイルは、必要になるまでは自動生成されない設計だったようで、書き込み先のファイルが無い状態で書き込み処理が走ると、エラーを出さずに黙って失敗していたのではないかと思われます（ここは公式に明言された仕組みではないので、あくまで症状からの推測です）。UI上は許可した体で進むのに、実際にはディスクに何も残っていない。だから次回起動時にまっさらな状態から確認が出る、というわけです。
二次情報として、GitHub issueのanthropics/claude-codeリポジトリにも近い症状の報告が複数あります。例えばIssue #7472は「’Yes, and always allow access to [directory] from this project’ を選んでもsettings.local.jsonに永続化されない」という内容で、現在のセッションだけ有効になり、再起動すると同じ確認が出る、という流れが記録されていました。ただし正直に書いておくと、このissueは「外部ディレクトリへのアクセス許可」がテーマで、今回のchangelogが指す「settings.local.json自体が存在しない新規プロジェクト」という条件とは完全には一致していません。同じ「always allowが保存されない」という症状の系譜にある関連issueとして紹介しますが、v2.1.252の修正が直接このissueをクローズしたと断定できる一次情報までは確認できませんでした。わからないことをわかったふりで書くよりは、ここまでが確認できた範囲だとはっきりさせておきます。
自分の環境で本当に踏んでいたか確認する
「もしかして自分も踏んでいたのでは」と思ったら、まず確認してみましょう。新規プロジェクトでClaude Codeを起動して、何かしらの権限確認でalways allow系の選択肢を選んだ直後に、別ターミナルから中身を覗いてみます。
cat .claude/settings.local.jsonここで許可した内容がJSONとして反映されていれば成功です。何も表示されない、あるいはファイル自体が無ければ、まさにこのバグを踏んでいる状態です。v2.1.252より前のバージョンを使っている場合は、まずアップデートしてみてください。
claude --version
claude updatev2.1.252以降であれば、公式changelogの記載通りこの症状はもう直っているはずです。正直に書いておくと、この記事は公式changelogとissueの内容を読み込んで書いたもので、手元で旧バージョンを意図的に再現して直った前後を実機比較したわけではありません。もし試してみて「まだ直っていない」というケースに遭遇したら、ぜひコメントで教えてください。
アップデートできない時の回避策
諸事情ですぐにアップデートできない場合、対症療法ですが回避策はあります。.claude/settings.local.jsonを先に空のJSONとして自分で作っておく方法です。
mkdir -p .claude
echo '{}' > .claude/settings.local.jsonファイルが最初から存在していれば「書き込み先が無くて失敗する」という条件そのものに当てはまらなくなるので、追記としては成立しやすくなります。ただしこれはあくまで症状への対症療法で、根本的にはアップデートするのが本筋です。さすがに毎回このおまじないを唱えるくらいなら、素直にバージョンを上げたほうが早いと思います。
演習: 自分のプロジェクトで確認してみる
せっかくなので、自分の環境が今どうなっているか実際に確認してみましょう。手順は単純です。
1. 適当な空のディレクトリを新しく作る（例: mkdir claude-check && cd claude-check）
2. claude を起動する
3. 何か1つコマンド実行を含む指示を出し、always allow系の選択肢を選ぶ
4. 一度 claude を終了する
5. cat .claude/settings.local.json で中身を確認する
6. もう一度 claude を起動して、同じコマンドを含む指示を出してみる手順5でJSONの中に許可内容が入っていて、手順6で確認が出なければ成功です。もし手順5の時点でファイルが空、あるいは存在しないなら、古いバージョンのまま使っている可能性が高いです。ヒント: バージョンはclaude --versionで確認できます。v2.1.252より古い数字が出たら、それが原因です。
権限まわりの不具合は他にもある
Claude Codeの権限まわりは、ここ数か月でかなり機能が増えた領域です。以前–restrictedモードを試したときも感じましたが、権限の保存・適用・制限は動きが速く、ドキュメントを読んでも実際の挙動と微妙にズレていることがあります。フックまわりでも通知やブロックの形式が変わったばかりですし、auto modeのデフォルト挙動もリリースごとに調整が入っています。個人的には、権限系の挙動がおかしいと感じたら「まず自分の設定を疑う」より先に「まずchangelogとissueを見る」くらいがちょうどいいと思っています。1年もCLIツールを追いかけていると、大体のおかしな挙動は誰かがもう踏んでいます。
無人運用をしている身としては地味に痛い
私はこのブログの記事執筆や日々のタスク処理の一部をClaude Codeの無人ループに任せています。毎回人間が画面の前に座って確認ボタンを押すわけにはいかないので、権限の永続化がちゃんと効くかどうかは死活問題です。新規プロジェクトを立てるたびに毎回同じ確認で止まってしまうと、無人ループはそこで固まって進まなくなります。今回のバグは地味な見た目の割に、自動化を前提にした使い方をしている人ほど実害が大きいタイプの不具合だったと思います。逆に言えば、これが直ったv2.1.252以降は、新規プロジェクトを都度作ってはClaude Codeに任せる、という運用がやりやすくなったはずです。
まとめというほどでもないですが
新規プロジェクトでだけalways allowが効かない、次回また同じ確認が出る。これはv2.1.252（2026年8月31日）で修正された既知の不具合でした。もし今も同じ症状が出ているなら、まずバージョンを確認してみてください。もう直っている可能性が高いです。それでも直らない、あるいは別の条件で再現するという方がいたら、ぜひコメントで教えてください。私も無人でループを回しながら日々このあたりの挙動に振り回されているので、他の人の再現条件はかなり参考になります。
コメント