Claude Codeの"Always allow"が効かない・保存されない原因を公式ドキュメントとGitHub Issueで切り分けた
「Yes, and don't ask again」を選んでも毎回同じ許可を聞かれる問題を、allowルールの優先順位・workspace trust・Editツールとの競合など公式ドキュメントとGitHub Issueの一次情報から原因別に整理し、確認コマンドと対処法をまとめた。
エンジニアのゆとです。
Claude Codeで「Yes, and don’t ask again」を選んでAlways allowにしたはずなのに、次のセッションでまったく同じ確認プロンプトが出てくる。この現象、自分も一度踏んだことがあって、そのときは「まあバグだろう」で流してしまった。
でも今回ちゃんと公式ドキュメントとGitHub Issueを漁ってみたら、実は原因が1つじゃなかった。しかも一部は本当にAnthropic側のバグとして修正されていて、一部は「バグに見えるけど実は仕様通り」というやつだった。両方が同じ症状で報告されているせいで、ネット上の情報も混ざりがちになっている。
この記事では、「Always allowを選んだのに効かない」を原因別に切り分けて、それぞれの確認方法と対処法を一次情報ベースでまとめた。
まず症状を整理する
「Always allowが効かない」と言っても、実際には少なくとも4パターンある。
| パターン | 症状 | 正体 |
|---|---|---|
| A. allowルールが弱い | 保存はされているのに毎回聞かれる | 仕様。askルールに負けている |
| B. workspace trustが済んでいない | allowルールが一切効かない | 仕様。信頼されていないフォルダ |
| C. ファイル自体が作られていない | .claude/settings.local.json が存在しない | 過去のバグ(修正済み) |
| D. セッション中にファイルが書き換わる | 途中から急に効かなくなる | 未解決のバグ報告あり |
「バグを疑う前に、まず自分がどのパターンかを切り分ける」のが遠回りに見えて一番早い。順番に見ていく。
パターンA — allowルールは、askルールに勝てない
これが一番見落とされやすい。公式ドキュメントにはっきりこう書かれている。
つまり「Always allow」を選ぶ操作は、正確には「自分のローカルファイル(.claude/settings.local.json)にallowルールを1つ足す」だけの操作で、それより優先度が高いスコープ(プロジェクト共有設定やmanaged設定)に同じ対象へのaskルールが書かれていたら、そちらが勝つ。だから「保存はされているのに毎回聞かれる」という一見矛盾した状態が起きる。
チーム開発でCLAUDE.mdや.claude/settings.jsonをリポジトリにコミットしている場合、この状態にかなり遭遇しやすい。誰かが安全のためにaskルールを仕込んでいると、個人がいくら「Always allow」を押しても意味がない。
確認する方法はシンプルで、自分のファイルだけでなくプロジェクト側のファイルも見る。
# 自分のローカル設定(ここにallowルールが追加される)
cat .claude/settings.local.json
# チーム共有設定(ここにaskルールが仕込まれていないか確認)
cat .claude/settings.json
# 管理者設定(組織管理下の場合)
cat /Library/Application\ Support/ClaudeCode/managed-settings.json 2>/dev/nullsettings.json や managed設定側に同じコマンド・ツールへの ask ルールが見つかったら、これが原因になる。allowルールを増やしても解決しないので、askルール側を外すか、そのルールの意図を尊重して都度確認するかの判断になる。
パターンB — workspace trustが済んでいないと、allowルールごと無視される
これも仕様上の落とし穴だ。公式ドキュメントにこう書かれている。
初めて開くリポジトリや、CI/コンテナなど毎回まっさらな環境からClaude Codeを起動する場合、フォルダの信頼(workspace trust)がそもそも成立していない状態でセッションが始まる。この状態だと、.claude/settings.local.json に正しくallowルールが書かれていても無視され、プロンプトが出続ける。
厄介なのは、denyルールとaskルールは信頼の有無に関係なく即座に効くという非対称性で、「denyは効くのにallowだけ効かない」という報告の一部はこれが原因になっている。使い捨て環境やDocker上で毎回trustダイアログを通していない場合は、まずここを疑うといい。
パターンC — そもそも .claude/settings.local.json が作られていなかった(修正済みバグ)
ここからは実際にAnthropicがバグとして認めて直したケースになる。
2025年9月に報告されたIssueがまさにこれだった。
この系統の不具合は長らく尾を引いていて、2026年8月31日リリースのバージョン2.1.252で、ようやく公式が名指しで修正を認めている。
つまり「そのプロジェクトで一度も.claude/settings.local.jsonを作ったことがない」状態で「Always allow」を選ぶと、ファイル自体の新規作成に失敗して選択が保存されない、というピンポイントなバグだった。2.1.252より前のバージョンを使っている場合はこれに当たっている可能性が高い。
# 現在のバージョンを確認
claude --version
# 2.1.252未満なら、まずアップデートする
claude updateアップデート後も改善しない場合、次に疑うべきはファイルが「もう存在するのに」効かないパターンD、または前述のパターンA・Bになる。
パターンD — セッション中にファイルが書き換わり、メモリ上のキャッシュとズレる(未解決)
パターンCより厄介なのがこっちで、「ファイルはちゃんと存在していて、中身も正しいのに、途中から効かなくなる」というケースだ。
2026年3月に報告されたIssueが典型例になる。
「Closed as not planned」というステータスがついていて、恒久修正としては優先度が上がっていない状態だ。実務上の回避策としては、セッションの途中で.claude/settings.local.jsonを(自分の手動編集も含めて)いじった直後は、一度セッションを再起動して読み直させるのが一番確実になる。
# 現在のセッションを終了して再起動する
/exit
claudeこまめに/permissionsで状態を見ながら作業しているなら、ファイルを直接編集した後に毎回このワンクッションを挟む癖をつけておくと踏みにくくなる。
.gitignoreに出てこないのは、実はバグじゃない
「Always allowが保存されない」と隣接してよく出てくる不満に、「.claude/settings.local.jsonが.gitignoreに追加されない」というものがある。2025年11月にはこれもIssueとして報告されていた。
ただし現在の公式ドキュメントを読むと、これは想定される動きが違っていたことがわかる。
つまり「プロジェクトの.gitignoreを開いても載っていない」のは仕様通りで、実際に効いているかどうかはグローバル側の除外ファイルを見ないと確認できない。
# グローバルのgit除外設定がどこを指しているか確認
git config --global core.excludesFile
# 実際にsettings.local.jsonが除外対象になっているか確認
git check-ignore -v .claude/settings.local.jsongit check-ignoreが何も返さない場合、除外が効いていない。自分で手作業を追加した場合や、古いバージョンでこの自動処理が走らなかった場合は、プロジェクトの.gitignoreに明示的に追記しておくのが確実だ。
.claude/settings.local.json権限だけでなくAPIキーやトークンをうっかりsettings.local.jsonに書いてしまうケースもあるので、機密情報を扱うプロジェクトほどこの確認は省略しない方がいい。
git worktreeを使っている場合は、書き込み先そのものが変わる
worktreeで複数ブランチを並行作業している場合、もう一つ見落としがちな仕様がある。「Yes, and don’t ask again」で保存される先は、今いるworktreeの.claude/ではなく、メインのチェックアウト側のルートにある.claude/settings.local.jsonになる。
worktreeごとに別々の許可が効くと思い込んでいると、「なぜかworktreeを切り替えるたびに設定が共有されている(または逆に反映されない)」という混乱につながる。worktree運用まわりの設定の切り分けは別記事にまとめてあるので、複数worktreeで作業している場合はそちらも合わせて確認してほしい。
今すぐ確認する手順(まとめ)
原因の見当がつかない場合、上から順に試すと大体どこかで引っかかる。
# 1. バージョン確認(2.1.252未満ならまずアップデート)
claude --version
claude update
# 2. 自分のローカル設定を確認
cat .claude/settings.local.json
# 3. プロジェクト共有設定・managed設定にaskルールが仕込まれていないか確認
cat .claude/settings.json
cat /Library/Application\ Support/ClaudeCode/managed-settings.json 2>/dev/null
# 4. gitの除外設定が実際に効いているか確認
git check-ignore -v .claude/settings.local.json
# 5. 直前にsettings.local.jsonを編集していたら、一度セッションを再起動
/exit
claudeエラーメッセージが何も出ない「静かな不具合」なので、catで中身を目で見て確認するのが一番早い。
それでも直らない場合
上記をひと通り試しても改善しない場合、claude doctorで設定ファイルのパース状態を確認した上で、GitHub Issueに環境情報を添えて追記するのが次の手になる。
「permission denied」そのものが出るケースはまた別の原因系統になる。allowlistに入れているのに拒否される、という症状ならこちらを先に確認した方が早い。
FAQ
VS Code拡張とCLI、どちらで「Always allow」を選ぶべき?
VS Code拡張の承認カードは、保存先ファイルを選べる(プロジェクトの共有ファイルにするか自分のローカルファイルにするか)。一方CLIでは選択肢がなく、常に自分のローカルファイル(.claude/settings.local.json)にしか書き込まれない。チーム全員に同じ許可を反映したい場合はVS Code拡張側の操作を使うか、.claude/settings.jsonを直接編集してコミットする方が確実になる。
手動で .claude/settings.local.json を編集してもいい?
問題ない。ただし前述のパターンDの通り、Claude Code自身が実行中にこのファイルを書き換えるタイミングと衝突すると、メモリ上のキャッシュとズレて一時的に反映されなくなることがある。手動編集した直後は一度セッションを再起動して読み直させるのが安全だ。
permissions.allow に書いても効かないコマンドがある
allowルールの記法(ワイルドカードの位置やコマンドのパターンマッチ)が実際のコマンド文字列と一致していないケースも多い。ここは今回扱った「保存自体はされている」問題とは別の切り分けが必要で、settings.json全体の読み込みまわりの不具合は別記事で扱っている。
まとめ
「Always allowを選んだのに毎回聞かれる」は、1つの原因に決め打ちして調べると遠回りになる。allowルールがaskルールに構造的に負けているのか、workspace trustが済んでいないのか、ファイル自体が過去バグで作られていなかったのか(2.1.252で修正済み)、それとも実行中にファイルが書き換わってキャッシュとズレているのか(未解決)——症状は同じでも中身は全部別物だ。
まずはcat .claude/settings.local.jsonで保存されているかどうかを目で見て確認する。保存されているのに効かないならパターンA・B・Dのどれか、保存すらされていないならclaude --versionでバージョンを確認してパターンCを疑う。この切り分けさえできれば、あとは対処法自体はどれも数分で終わる話ばかりだ。
