Claude Code の権限設定：.env、Git、危険なコマンドを守る方法

Claude Code の設定では、開発者は誤った二択に陥りがちです。些細な読み取りコマンドを毎回承認するか、完全なバイパスである --dangerously-skip-permissions を有効にして、.env の漏えい、意図しない git push --force、プロジェクト環境の破損を招くか、という選択です。

どちらの極端も有効ではありません。安全な運用は最小権限の原則に基づき、読み取り、書き込み、シェル実行、バージョン管理を明確に分離します。

---

1. 権限マップ：読み取りから外部への影響まで

ファイルとコマンドを、次の 4 段階に分けます。

レベル	操作	既定ポリシー	例
1. コードの確認	プロジェクトファイルを読む	許可（承認不要）	cat、grep、src/ のソース閲覧
2. シークレットと設定	.env、キー、トークンへのアクセス	厳格に禁止	.env*、id_rsa、*.pem、credentials.json
3. ファイル編集	コードの作成・変更	ワークスペースの範囲内で許可	write_to_file、replace_file_content
4. 危険な Shell / Git	パッケージ管理、破壊的操作	手動承認が必須	rm -rf、git push --force、npm publish、DROP TABLE

---

2. .env ファイルとプロジェクトのシークレットを隔離する

Transport Layer Security（TLS）は、ネットワーク上の API トラフィックを暗号化します。しかし、機密の認証情報がモデルのコンテキストウィンドウ、エラーログ、handoff の要約に入ることまでは防げません。

Claude Code に非公開の認証情報を取り込ませないために、次を行います。

1. シークレットを含むすべての環境ファイルを .gitignore に追加します。
2. ダミー値だけを入れた .env.example を用意します。これにより、エージェントは実行時の値を見ずに変数名を理解できます。
3. CLAUDE.md または AGENTS.md に、明確な境界ルールを記載します。

## シークレット保護ルール

- `.env`、`.env.local`、秘密鍵ファイルの内容を確認、出力、転送してはならない。
- 必要な設定キーは `.env.example` を確認する。

[!IMPORTANT] API キーの管理：Claude Code の API キーはローカル環境で設定し、リポジトリのファイルにコミットしてはいけません。安全な接続手順は BetterToken の Claude Code ドキュメントに従ってください。

.gitignoreは誤ったcommitを防ぎますが、エージェントによるfileの読み取りは防ぎません。CLAUDE.mdやAGENTS.mdの指示は意図であり、技術的な境界ではありません。現在のpermission ruleとOS-level sandboxを併用します。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": [
        "./**/.env",
        "./**/.env.*",
        "./secrets"
      ]
    }
  }
}

Read denyはbuilt-in file toolsと認識されたfile commandに適用されます。任意のPythonやNode subprocessは別の方法で読む可能性があるため、OS境界にはsandboxが必要です。failIfUnavailableとallowUnsandboxedCommandsは、隔離できないときに非隔離実行へfallbackせず停止させます。Native Windowsではsandboxが非対応なので、WSL2またはcontainerを使います。Managed environmentではproject settingsがpolicyを弱めないよう管理者が固定します。

---

3. Git とコマンドを制御する優先チェックリスト

Claude Code にタスクを実行させるときは、まず次の順序で評価します。

エージェントがコマンドを提案する
  │
  ├─> 破壊的なパターン（rm -rf、drop、force push）を含むか？
  │     └─> はい：却下するか、開発者の監督下で手動実行する
  │
  └─> .git の内部、.env ファイル、外部ネットワークに触れるか？
        │
        ├─> はい：明確な理由を求め、コマンドの範囲を制限する
        │
        └─> いいえ：対象ブランチ内での実行を承認する

段階的なガードレール

1. 手順 1：Git の変更をゲートする。 手動の git diff --check とテスト実行なしに、main への自動直接 push を許可しないでください。
2. 手順 2：パッケージの導入を隔離する。 npm install <package> やリモートの curl スクリプトは、信頼できない依存関係やサプライチェーンのリスクを避けるため、手動で確認します。
3. 手順 3：ディレクトリの範囲を制限する。 エージェントのワークスペースを、特定の機能フォルダまたは専用 Git worktree に制限します。

---

4. Production accessは別の境界

Local permissionはproductionのIAM、network policy、system approvalを代替しません。原則はaccessなしです。診断に必要なら、resource-scopedでshort-livedなread-only roleを発行します。Writeにはcommand、target、time window、validation、observer、rollbackを明記した別approvalが必要です。結果が不明ならretry前にcurrent stateを読みます。Audit logにはidentity、resource、action、resultを残しますが、secret valueやsensitive payloadは残さず、temporary credentialは終了後にrevokeします。CredentialをHANDOFF.mdへコピーしてはいけません。

5. テスト用ワークスペースで権限を検証する

Claude Code に重要なリポジトリへのアクセスを与える前に、サンドボックスで境界を検証します。

1. 使い捨てのテストブランチを作成します：git checkout -b test/permission-check。
2. 偽のテスト用シークレットを含むダミーの .env ファイルを追加します。
3. 認証モジュールをリファクタリングするようエージェントに依頼します。
4. 次を確認します。
   • 探索中にエージェントがダミーの .env を読んでいないこと。
   • シークレットトークンがエラーログ、コメント、git diff に漏れていないこと。
   • 許可していないファイルにアクセスせず、ユニットテストが実行できること。
5. 境界を確認できたら、テストブランチを削除します。

このように権限の境界を明確にすると、認証情報を守りながら自律的な実行速度も維持できます。