コンテンツにスキップ

permission mode を選ぶ

tier 1(まず入れる)確認 1 か月前(2026年8月23日)

どこまで来たら使えたと言えるか

面: 操作が異なる — ターミナルとデスクトップで操作が違うので、条件を分けています

段達成したと言える状態
1. 触るターミナルShift+Tab で default → acceptEdits → plan を一周し、ステータスバーの表示が変わることを見た

デスクトップ送信ボタン隣のモードセレクタ(Cmd+Shift+M)を開き、Manual / Accept edits / Plan を実際に切り替えた

2. 入れるターミナル調べもの・実装・危険な作業でどのモードから始めるかを決め、permissions.defaultMode か起動フラグで固定してある

デスクトップセレクタで選んだモードがフォルダごとに記憶され defaultMode より優先されることを踏まえて使っている(Plan だけは現セッション限り)

3. 効かせるターミナルモードでは緩められない境界(protected paths、deny ルール、会話で述べた境界)を説明でき、拒否されたときに /permissions の Recently denied から辿れる

デスクトップAuto の可用条件と、cloud セッションが Accept edits / Plan / Auto しか持たないことを言える。dontAsk が CLI 専用であることも知っている

何のためのものか

Claude がファイル編集・シェルコマンド実行・ネットワークリクエストの前に確認を求める頻度を決めるモード。モードは基準を決めるだけで、permission rule を重ねて特定のツールを事前承認・ブロックできる。

触る

Shift+Tab を押して一周させる。既定の循環は default → acceptEdits → plan。

モード確認なしで実行されるもの
default読み取りのみ
acceptEdits読み取り、ファイル編集、mkdir / touch / mv / cp などの一般的なファイルシステムコマンド
plan読み取り。auto mode が利用可能な場合は classifier が承認したコマンドも
autoすべて(バックグラウンドの安全チェック付き)
dontAsk事前承認済みのツールのみ
bypassPermissionsすべて

default は UI 上 Manual と表示される。設定値は default で、hooks と SDK 統合はこちらを使う。

入れる

作業の種類ごとに、どこから始めるかを決める。

  • 調査・設計から入るとき — plan。Claude は調べて提案するが変更しない。Shift+Tab、プロンプト先頭の /plan、claude --permission-mode plan のどれでも入れる。計画提示時に Yes, and use auto mode / Yes, manually approve edits / No, keep planning から選ぶ
  • 書かせると決めたあと — acceptEdits。自動承認は作業ディレクトリまたは additionalDirectories 内のパスに限られる
  • 既定を固定する — settings の permissions.defaultMode、1 セッションだけなら --permission-mode

auto は classifier モデルが実行前に行動をレビューする。defaultMode: "auto" を .claude/settings.json や .claude/settings.local.json に書いても無視される(リポジトリが自分自身に auto mode を与えられないようにするため)。~/.claude/settings.json に置く。

効かせる

モードでは緩められないものを知る。ここが分かると、勝手に止まる理由が読める。

  • protected paths — .git、.claude、.vscode、.bashrc、.npmrc、.mcp.json などへの書き込みは、bypassPermissions を除いて自動承認されない。permissions.allow ルールを書いても事前承認にならない(安全チェックが allow ルール評価より前に走る)
  • deny ルールと明示的な ask ルール — bypassPermissions を含むすべてのモードで適用される
  • 会話で述べた境界 — 「push しないで」のような発言を classifier はブロック信号として扱う。ただし保存されず、context compaction で失われる。確実に守らせたいなら deny ルールにする
  • 止まったときの辿り方 — 拒否された行動は /permissions の Recently denied タブに出る。r で手動承認して再試行できる

auto mode には自動停止がある。classifier が 3 回連続、または累計 20 回ブロックすると一時停止してプロンプトを出す状態に戻る(閾値は設定できない)。

落とし穴

  • bypassPermissions は prompt injection への保護を提供しない。 分離されたコンテナ・VM・インターネットに接続しない dev container でのみ使う。root / sudo での起動は拒否される
  • bypassPermissions には後から入れない。 起動時に permissions.defaultMode: "bypassPermissions" かフラグで有効にしたセッションでのみ循環に現れる
  • auto mode に入ると広い allow ルールが落ちる。 Bash(*) やワイルドカード付きインタプリタは無効化され、Bash(npm test) のような狭いルールだけが引き継がれる(抜けると復元される)
  • auto mode が「使えない」と言われたら要件未達で、待っても直らない。 一方 "cannot determine the safety" は classifier リクエストの失敗で、通常は一時的
  • dontAsk は循環に現れない。--permission-mode dontAsk で入る。本来プロンプトを出す呼び出しはすべて自動拒否される

根拠と前後

このページが書ける範囲は、根拠にした facts に書かれていることだけです。 仕様そのものはそちらを読んでください。