Claude CodeのAlways allowが既定ボタンになる不具合と誤許可の消し方
Claude Code Desktopの許可プロンプトで主ボタンが「Always allow」になったという報告があります。見分け方と、意図せず保存されたルールやモードを元に戻す手順をまとめました。
Claude Code Desktopの許可プロンプトで、いちばん目立つ主ボタンが「Allow once」ではなく「Always allow」に変わったという報告が、GitHub Issue #102136に集まっています。Enterキーを反射的に押すだけで、承認した覚えのない恒久ルールが保存されるため、手元の設定を見直す価値があります。Issueは2026年10月17日時点でopenのままで、修正の案内は出ていません。
ここで扱うのは、Desktopで主ボタンが変わった件の見分け方と、誤って保存されたルールやモードの戻し方です。「Yes, and don't ask again」で何がどこに保存されるかの一般的な仕組みは許可プロンプトで何が保存されるかにあります。
Issue #102136で報告されている内容
報告者はDesktopアプリのビルド2.37337.1(2026-10-13付け)で、次の変化を確認しています。
- 主ボタンが「Always allow」(
⇧⌘↵)になった - 「Allow once」はドロップダウンの矢印の奥に移った
- 以前の同種の報告(#48550、#48409)は、更新がないまま自動クローズされていた
再現手順は単純です。許可リストに何もない状態で、Claudeにpython3 -I -c "print('hello')"のような設定のないBashコマンドを実行させると、新しい形のプロンプトが出ます。
コメント欄には、環境の違う報告が続いています。
| 報告者の環境 | 内容 |
|---|---|
| macOS(新規インストール) | 内容主ボタンがAlways allow。Allow once(⌘↵)と「Allow and switch to Auto」はドロップダウン内 |
| Windows版アプリ | 内容同じ挙動の変化を確認 |
| Linux版アプリとWeb | 内容同じ。リモートセッションでは以前Allow onceが直接のボタンだったと証言 |
Linux版・Web版の報告者は、コードやコマンドのプレビュー領域が画面の半分ほどに縮んだことも挙げています。
気づきにくい副作用 — Manualモードがほどける
コメントの一つは、Bashだけでなくファイル編集にも影響があると指摘しています。Manualモードでファイル編集を既定ボタンで承認すると、そのセッションの権限モードがAccept editsに切り替わり、以降の編集がプロンプトなしで通るというものです。目印はモード選択欄の表示だけです。
同じ報告者のセッションでは、.claude/settings.local.jsonにBash(gh api *)とBash(python3 -I -c ' *)の2件が自動で追加されていました。すべての編集を確認するためにManualを選んでいた人ほど、意図と逆の結果になります。
なお、この挙動は報告者1人のものです。再現手順は「Manualに設定 → ファイル編集を依頼 → 主ボタンを押す → モード選択欄を見る」の3段で、自分の環境でも短時間で確かめられます。
自分のプロンプトが該当するかを見分ける
画面の見た目で判断できます。
- Desktopアプリのバージョンを確認する(報告のビルドは2.37337.1)
- 設定のないBashコマンドを実行させ、プロンプトを出す
- 主ボタンの文言を読む。「Always allow」なら報告と同じ状態
ターミナルのClaude Codeでは、公式ドキュメントのBashプロンプトの図が「Yes」「Yes, and don't ask again for: …」「Yes, and switch to auto mode」「No」の順に選択肢を並べています。Issueが扱うのはDesktopのプロンプトで、CLIのプロンプトとは別の画面です。
誤って保存されたルールを消す手順
Bashコマンドの「ずっと許可」は、Gitリポジトリのルートにある.claude/settings.local.jsonにallowルールとして書き込まれます。リポジトリの外やWindowsなど、保存先がリポジトリのルートにならない場合もあります。いったん保存されたルールは、次回以降のセッションでも有効です。
保存先はワークツリーを使っている場合、メインのチェックアウトのルートに解決されます。ワークツリーやサブディレクトリで押したAlways allowも、リポジトリ全体のセッションに効きます。v2.1.211より前のClaude Codeは、起動したディレクトリにルールを保存していました。古い環境で承認したルールが、サブディレクトリの.claude/settings.local.jsonに残っていることもあります。探して見つからないときは、起動場所の配下も見てください。
保存期間は承認の種類で変わります。BashコマンドとWebFetchのドメイン、WebSearchは、リポジトリごとに恒久的に保存されます。ファイル編集だけがセッション終了までです。確かめる場所も分かれます。Bash・ドメイン・検索の承認は設定ファイルか/permissions、ファイル編集の承認はモード選択欄です。
消し方は2通りあります。
/permissionsで消す
Claude Codeのセッションで/permissionsを開くと、全ルールと由来する設定ファイルが一覧できます。見覚えのないルールを選んで削除します。セッション中に行った追加・削除は、Claudeの次のツール呼び出しから反映されます。
/permissions設定ファイルを直接編集する
.claude/settings.local.jsonを開き、permissions.allowから該当の行を取り除きます。報告にあった2件を消した後の形は、次のようになります。
{
"permissions": {
"allow": []
}
}実際のファイルでは、意図して残したルールまで消さないよう、allowの中身を1行ずつ見て判断してください。編集前に内容を控えておけば、消しすぎても戻せます。
ルールの保存先と優先順位
権限ルールは.claude/settings.local.json以外にも書けます。公式ドキュメントが挙げる設定ファイルは4種類です。
| 範囲 | ファイル |
|---|---|
| ユーザー | ファイル~/.claude/settings.json |
| プロジェクト | ファイル.claude/settings.json |
| ローカル | ファイル.claude/settings.local.json |
| 管理者設定 | ファイル組織が配布するmanaged settings |
Always allowで増えるのはローカルのファイルです。ただし/permissionsの一覧には、各ルールの由来となる設定ファイルが並びます。見覚えのないルールが出てきたら、由来を見て消す場所を決めてください。
優先順位は管理者設定が最上位で、コマンドライン引数でも上書きできません。どの階層であれdenyされたツールは、ほかの階層から許可に戻せません。組織の管理者設定で拒否されているコマンドは、Always allowを押しても通らない、ということです。
権限モードの名前と、モードが変わったときの戻し方
Desktopのモード選択欄の表示名と、設定ファイルのpermissions.defaultModeの値は対応しています。
| Desktopの表示 | 設定値 | 挙動 |
|---|---|---|
| Manual | 設定値default | 挙動ファイル編集もコマンド実行も確認する |
| Accept edits | 設定値acceptEdits | 挙動ファイル編集とmkdir・mvなどの基本操作を確認なしで通す |
| Plan | 設定値plan | 挙動探索だけして、ソースは編集しない |
| Auto | 設定値auto | 挙動通常の確認なしで進め、バックグラウンドの分類器が依頼との整合を確かめる |
| Bypass permissions | 設定値bypassPermissions | 挙動確認を出さない。隔離環境向け |
旧バージョンのDesktopは、Manualを「Ask permissions」、Accept editsを「Auto accept edits」と表示していました。古い記事や画面で別の名前を見かけたら、この表で読み替えられます。
ドロップダウンの「Allow and switch to Auto」を押した場合も、結果はモードの切り替えです。戻すには、モード選択欄でManualを選び直します。選んだモードはフォルダごとに記憶され、defaultModeの設定よりも優先されます(Planだけは現在のセッション限り)。このため、設定ファイルのdefaultModeを直しても、そのフォルダでは選択欄の記憶のほうが効き続けることがあります。
Autoが選択欄に出るのは、利用できる環境だけです。Desktopには、Autoを切るための独立した設定項目もありません。使わせたくない組織では、permissions.disableAutoModeを"disable"にする方法があり、管理者設定に置けば利用者側では上書きできません。
見落としやすい確認先
- ファイル編集の「Always allow」は、ドキュメントの表ではセッション終了までの承認で、設定ファイルには書かれない。終了すれば残らないので、消す作業は要らず、残るのはセッション中の挙動だけ
- Manualから切り替わったAccept editsは、モード選択欄でManualに戻す。Desktopでは選んだモードがフォルダごとに記憶される
- 外部サイトの閲覧で選んだ「Always allow」は、Desktopの設定画面から取り消せる。サイト単位で承認され、サブドメインは別扱い
再発を減らす設定
主ボタンの既定を変える設定項目はありません(Issue報告時点のビルド)。コメント欄でも「設定のトグルにしてほしい」という要望が出ています。ボタンの選び方に頼らず、ルール側で守る方法があります。
- 実行させたくないコマンドを
denyルールにしておく。評価順はdeny、ask、allowで、denyに一致すれば後からAlways allowを押してもブロックされる - 確認したいコマンドは
askルールに入れる。askはallowより先に評価され、一致すれば必ず確認が出る
{
"permissions": {
"deny": ["Bash(rm -rf *)"],
"ask": ["Bash(python3 *)"]
}
}この例のようにaskへ入れたコマンドは、保存済みのallowルールがあっても確認が出ます。反射的に主ボタンを押しても、denyに当たるものは通りません。
補足 — 症状が似て見える別の問題
「常に許可を選んだのに聞かれ続ける」という逆の症状は、原因が別です。切り分けはClaude Codeのalways allowが効かない原因と対処法にまとめています。許可プロンプトに一言添える操作はClaude Codeの権限プロンプトにTabでコメントを添える方法、過去に許可した操作を整理する方法は/fewer-permission-promptsで許可プロンプトを自動整理するが扱っています。ルールの置き場所と書き方の基礎はClaude Code settings.json完全ガイドの範囲です。
まとめ
主ボタンがAlways allowになった報告は、Desktopの複数OSで出ており、Issueはopenのままです。当面は、プロンプトの文言を読んでから押すこと、/permissionsと.claude/settings.local.jsonに身に覚えのないルールが増えていないかを定期的に見ること、Manualで始めたセッションのモード表示を確かめることの3点が、実害を抑える手段になります。