パーミッションモードを使い分ける

症状・対象

ツール実行の確認が多すぎて進まない、または自動許可の範囲が広すぎて不安な人が対象です。まず読み取り専用で調べ、実装時だけ編集を許可すると、速度と安全性を両立できます。

最短解決

1. 未知のリポジトリは plan で起動し、変更範囲を確認する。
2. 計画に合意したら終了し、acceptEdits で起動し直す。
3. 繰り返す安全なコマンドだけ allow、外部送信や秘密情報は ask / deny に固定する。

コピペ例

調査と実装をモードで分けます。

# 調査だけを行う
claude --permission-mode plan

# 計画確認後、編集を許可して実装する
claude --permission-mode acceptEdits

プロジェクトの .claude/settings.json には、必要最小限のルールだけを置きます。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Bash(rm -rf:*)"
    ]
  }
}

期待結果

• plan では調査と計画が進み、ファイル編集は実行されない。
• acceptEdits では編集の確認回数が減る。
• git push と依存追加は確認され、.env の読み取りは拒否される。

検証

セッション内で次を実行し、現在のモードとルールを確認します。

> /permissions

続けて「git diff を確認して」と依頼し、許可なしで読めることを確認します。「git push は実行せず、許可が必要かだけ確認して」と依頼した場合は、実行前に確認対象として扱われれば設定成功です。

落とし穴

• bypassPermissions は権限検査自体を飛ばします。日常開発や秘密情報を持つ環境では使いません。
• dontAsk を「危険操作は必ず止まる」と解釈しないでください。安全境界は明示した ask / deny で作ります。
• mcp__server__* のような MCP ワイルドカードは使いません。サーバー全体なら mcp__server、個別なら完全なツール名を指定します。
• ルール変更後は既存セッションの思い込みに頼らず、/permissions で実効設定を確認します。

次の一手

• -p フラグでワンショット実行を行う — 非対話実行にも同じ最小権限の考え方を適用する
• Hook でツール実行を自動化する — 許可ではなく検証を自動化する

# default モード（毎回確認ダイアログ）
Claude: "src/api/users.ts を編集してもよいですか？"
あなた: "はい"
Claude: "src/api/orders.ts を編集してもよいですか？"
あなた: "はい"
# 繰り返しの承認で集中力が途切れる

# acceptEdits モードで編集を自動許可
$ claude --permission-mode acceptEdits

# ファイル編集は自動で進み、
# git push などの危険操作だけ確認が入る