権限モードと、確認を減らす方法

Claude Code は、ファイルを書き換えたり、コマンドを実行したりする前に、「実行してよいか」を確認することがあります。この確認は、意図しない操作を防ぐための仕組みです。一方で、確認が多すぎると、作業が進みません。このページでは、確認が出る仕組みを整理し、安全さを保ったまま確認を減らす方法をまとめます。

この記事で分かること

どの操作で確認が出て、どの操作では出ないのか
6 つの権限モードの違いと、切り替え方
権限ルール（allow、ask、deny）の働きと、書き方
Claude が確認を求める回数が多いときに、利用者ができること
どの設定にしても確認が残る操作
Claude のコマンドが、PC の上で何をできるか。それを OS の仕組みで制限するサンドボックスの働きと、このサイトで試した結果

用語の整理

用語	意味
権限の確認（permission prompt）	Claude が操作を実行する前に、利用者に「実行してよいか」を尋ねる表示
権限モード（permission mode）	確認なしで実行できる操作の範囲を、セッション全体について決める設定
権限ルール（permission rule）	特定のツールやコマンドについて、許可する、確認する、禁止する、を個別に決める設定
allow / ask / deny	権限ルールの 3 つの種類。allow は確認なしで許可、ask は毎回確認、deny は禁止
作業フォルダー（working directory）	Claude が、確認なしでファイルを読める範囲。既定では、セッションを始めたフォルダー
分類器（classifier）	auto モードで、利用者の代わりに操作を審査する、別のモデル
保護されたパス（protected path）	`.git` や `.claude` など、書き込みが自動では許可されないフォルダーやファイル
管理設定（managed settings）	組織の管理者が配布する設定。利用者やプロジェクトの設定では、上書きできない
サンドボックス（sandbox）	Claude が実行するコマンドを、OS の仕組みで囲う機能。書き込める場所と、通信できる相手を制限する

確認が出る仕組み

確認が出るかどうかは、次の 3 つで決まります。

操作の種類：読むだけの操作か、書き換えや実行を伴う操作か
権限モード：セッション全体で、どこまでを確認なしにするか
権限ルール：特定のツールやコマンドについての、個別の許可や禁止

まず、操作の種類ごとの基本の動きです。次の表は、Manual（すべての操作を自分で確認するモード）での動きです。

操作の種類	例	確認が出るか
読み取り	ファイルを読む、検索する	出ない（作業フォルダーの中の場合）
シェルのコマンド	`npm run build`、`git commit`	出る。ただし、読み取り専用のコマンドは出ない
ファイルの変更	ファイルの編集、作成	出る
Web ページの取得	指定した URL の内容を読む	出る。ただし、あらかじめ許可されているドキュメントのサイトは出ない
Web 検索	検索する	出る

読み取り専用のコマンド

Claude Code は、あらかじめ決められた一部のコマンドを「読み取り専用」と見なし、どのモードでも確認なしで実行します。公式ドキュメントが挙げているのは、ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd と、git の読み取りだけの使い方です。この一覧は、設定で変えられません。

ただし、これらのコマンドでも、確認が出る場合があります。たとえば、ls > out.txt のように結果をファイルへ書き出すと、書き出し先についての確認が加わります。

権限モード

権限モードは、セッション全体について、確認なしで実行できる範囲を決めます。

モード（設定での値）	画面での名前	確認なしで実行されるもの	向いている場面
`default`	Manual	読み取りだけ	すべての操作を自分で確認したい。慎重に扱いたい作業
`acceptEdits`	Accept edits（VS Code では Edit automatically）	読み取り、ファイルの編集、よく使うファイル操作のコマンド（`mkdir`、`touch`、`mv`、`cp` など）	変更内容は、あとでまとめて確認する
`plan`	Plan	読み取り。ファイルは編集しない	変更する前に、調査と計画だけをさせたい
`auto`	Auto	すべて。ただし、分類器が、裏で操作を審査する	時間のかかる作業。確認の多さを減らしたい
`dontAsk`	（ターミナル版だけ）	作業フォルダーの中の読み取りと、あらかじめ許可した操作だけ。確認が必要になる操作は、確認せずに拒否する	自動実行の仕組みの中で、決めた操作だけをさせたい
`bypassPermissions`	Bypass permissions	すべて	外部から切り離されたコンテナーや仮想マシンの中だけ

acceptEdits：ファイルの編集は確認しない

ファイルの編集と、よく使うファイル操作のコマンドを、確認なしで実行します。対象は、作業フォルダーの中のパスだけです。それ以外のシェルのコマンド（ビルド、テスト、git push など）は、これまでどおり確認が出ます。

変更内容を、1 つずつその場で承認するのではなく、あとから差分でまとめて確認したいときに向いています。

plan：調べて、計画を立てるだけ

Claude は、ファイルを読み、調査のためのコマンドを実行しますが、ファイルは編集しません。計画を示したところで止まり、利用者が計画を承認してから、実行に移ります。

auto：分類器が、利用者の代わりに審査する

auto モードでは、日常的な確認が出なくなります。その代わりに、分類器と呼ばれる別のモデルが、操作を実行前に審査します。依頼された範囲を超える操作や、Claude が読んだ内容にそそのかされたように見える操作などは、分類器が止めます。

公式ドキュメントには、次の注意が書かれています。

auto モードは確認を減らすが、安全を保証するものではない。方向性を信頼できる作業に使うもので、慎重に扱うべき操作での確認の代わりにはならない。
分類器が、続けて 3 回、または合計で 20 回、操作を止めると、auto モードは一時停止し、通常の確認に戻る。

auto モードを使える条件は、対応しているモデルであることと、組織の管理者が無効にしていないことです。

bypassPermissions：確認を行わない

確認と安全のための検査を行わずに、操作をそのまま実行します。公式ドキュメントは、外部から切り離されたコンテナーや仮想マシンの中だけで使うように、警告しています。普段の PC で確認を減らす目的には、使いません。

モードの切り替え方と、始まるときのモード

セッションの途中で、いつでもモードを切り替えられます。

使う場所	切り替え方
ターミナル版	`Shift+Tab` を押すたびに、順番に切り替わる
デスクトップアプリ	送信ボタンの横にある、モードの選択欄
VS Code の拡張機能	入力欄の下にある、モードの表示をクリックする

新しいセッションが、どのモードで始まるかは、使う場所ごとに決まり方が違います。

使う場所	始まるときのモードの決まり方
ターミナル版	① 起動時の指定（`--permission-mode`）→ ② 設定ファイルの `permissions.defaultMode` → ③ 組み込みの既定値、の順で、最初に当てはまるもの。組み込みの既定値は、バージョン 2.1.283 以降では `auto`
デスクトップアプリ	設定ファイルの `permissions.defaultMode` を読む。ただし、選択欄で選んだモードは、フォルダーごとに記憶され、`defaultMode` より優先される（Plan は、そのセッションだけ）
VS Code の拡張機能	① 拡張機能の設定 `claudeCode.initialPermissionMode` → ② 選択欄で最後に選んだモード → ③ 管理設定か `~/.claude/settings.json` の `permissions.defaultMode` → ④ 組み込みの既定値、の順。プロジェクトの `.claude/settings.json` は、始まるときのモードには使われない

設定ファイルで、始まるときのモードを指定する例です。~/.claude/settings.json に、次のように書きます。

json

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

1 つ、注意があります。auto と bypassPermissions は、プロジェクトの設定ファイル（.claude/settings.json、.claude/settings.local.json）に書いても、効きません。auto で始めたい場合は、利用者ごとの設定ファイル（~/.claude/settings.json）に書きます。

権限ルール

権限モードが全体の基準を決めるのに対して、権限ルールは、特定のツールやコマンドについて、個別に決めます。

ルールの種類	働き
allow	当てはまる操作を、確認なしで許可する
ask	当てはまる操作のたびに、確認する
deny	当てはまる操作を、禁止する

評価の順番

ルールは、deny、ask、allow の順に調べられ、最初に当てはまったものが結果になります。ルールの細かさは、順番に影響しません。

このため、広い deny ルールの中に、allow ルールで例外を作ることはできません。たとえば、Bash(aws *) を deny にすると、Bash(aws s3 ls) を allow に書いても、禁止されたままです。

もう 1 つ、大切な点があります。権限ルールを守らせているのは、モデルではなく、Claude Code の本体です。会話の中の指示や CLAUDE.md に「このコマンドは実行しないで」と書くことは、Claude の行動の方針にはなりますが、実行を止める仕組みにはなりません。確実に止めたい操作は、deny ルールに書きます。

書き方

ルールは、ツール名 または ツール名(条件) の形で書きます。設定ファイルでは、次のようになります。

json

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

この例では、npm のスクリプトの実行と git commit は確認なしで実行され、git push で始まるコマンドは禁止されます。

シェルのコマンドのルールでは、* が「任意の文字列」を表します。

ルール	当てはまる	当てはまらない
`Bash(npm run build)`	`npm run build`	`npm run build --watch`
`Bash(npm run *)`	`npm run build`、`npm run test --watch`	`npm install`
`Bash(ls *)`	`ls -la`、`ls`	`lsof`
`Bash(ls*)`	`ls -la`、`lsof`

書くときの注意は、次のとおりです。

* は、サブコマンドのあとに置く。 Bash(git log *) は git log だけを許可するが、Bash(git *) は、git のすべてのコマンドを許可してしまう。
&& などでつないだコマンドは、それぞれが調べられる。 Bash(safe-cmd *) を許可しても、safe-cmd && other-cmd の other-cmd は、許可されない。
ファイルの読み書きは、Read(パス) と Edit(パス) で書く。 たとえば、Read(./.env) を deny にすると、そのファイルを Claude のファイル用のツールで読めなくなる。

ルールの書き方には、ほかにも細かい決まりがあります。設定ファイルの置き場所と優先順位とあわせて、「04. 設定ファイルの仕組み」で扱う予定です。

確認の画面からルールを保存する

確認の画面には、「はい」「いいえ」のほかに、「はい、今後は確認しない」にあたる選択肢が出ることがあります。これを選ぶと、その操作についての allow ルールが、自動で保存されます。

操作の種類	「今後は確認しない」を選んだときの有効な範囲
シェルのコマンド	そのリポジトリと、そのコマンドについて、以後ずっと
ファイルの変更	そのセッションが終わるまで
Web ページの取得	そのリポジトリと、そのドメインについて、以後ずっと

ずっと有効になるルールは、リポジトリの .claude/settings.local.json に保存されます。このファイルは、自分だけの設定を置く場所です。

確認の画面に、この選択肢が出ないこともあります。その場合は、その場で 1 回だけ承認するか、ルールを自分で設定ファイルに書きます。

作業フォルダー

Claude は、既定では、セッションを始めたフォルダーの中のファイルに、アクセスできます。このフォルダーを、作業フォルダーと呼びます。作業フォルダーの中の読み取りには、確認が出ません。

作業フォルダーの外のファイルを読もうとすると、確認が出ます。別のフォルダーも日常的に使う場合は、作業フォルダーを追加できます。

追加する方法	内容
起動時	ターミナル版で、`--add-dir <パス>` を付けて起動する
セッションの途中	`/add-dir` コマンドを使う
設定として残す	設定ファイルの `additionalDirectories` に書く

追加したフォルダーは、元の作業フォルダーと同じ扱いになります。読み取りは確認なしで、編集は、そのときの権限モードに従います。

Claude が確認を求める回数が多いとき、利用者ができること

ここまでで見たとおり、Claude が確認を求めるかどうかは、操作の種類、権限モード、権限ルールの 3 つで決まります。確認が多いと感じたときは、どの種類の操作で確認が出ているかを見ると、3 つのうちのどれを調整すればよいかが分かります。

確認が出る場面ごとに、原因と、利用者ができることを整理します。

ファイルを編集するたびに、確認が出る

Claude がファイルを書き換えるたびに、確認が出る場合です。

原因	利用者ができること
権限モードが Manual になっている	Accept edits に切り替える。ファイルの編集は、確認なしで行われるようになる

同じコマンドを実行するたびに、確認が出る

ビルドやテストなど、何度も実行するコマンドで、毎回確認が出る場合です。

原因	利用者ができること
そのコマンドを許可する allow ルールがない	確認の画面で「今後は確認しない」にあたる選択肢を選ぶ。または、設定ファイルの `permissions.allow` に、そのコマンドのルールを書く

どのコマンドでも、確認が出る

特定のコマンドにかぎらず、コマンドを実行するたびに確認が出る場合です。

原因	利用者ができること
権限モードが Manual で、allow ルールもない	Auto に切り替える。または、よく使うコマンドを、allow ルールにまとめて書く

作業フォルダーの外のファイルを読むときに、確認が出る

セッションを始めたフォルダーの外にあるファイルを、Claude が読もうとして、確認が出る場合です。

原因	利用者ができること
そのフォルダーが、作業フォルダーに含まれていない	作業フォルダーに追加する。または、そのフォルダーでセッションを始める

新しいセッションを始めるたびに、Manual に戻っている

セッションの途中でモードを切り替えても、次のセッションでは、また Manual で始まる場合です。

原因	利用者ができること
始まるときのモードが、Manual に決まっている	設定ファイルの `permissions.defaultMode` を設定する。VS Code の拡張機能では、拡張機能の設定（`claudeCode.initialPermissionMode`）も確かめる

allow ルールを書いたのに、確認が出る

許可するルールを書いたはずの操作で、確認が出続ける場合です。原因は、いくつか考えられます。

原因	利用者ができること
ask ルールや deny ルールが、先に当てはまっている	ルールは、deny、ask、allow の順に調べられる。ask ルールや deny ルールに、同じ操作が当てはまっていないかを確かめる
`&&` などでつないだ、別のコマンドが、ルールに当てはまっていない	つないだコマンドは、それぞれが調べられる。当てはまっていないコマンドのルールを足す
ルールの `*` の位置が合っていない	実際に実行されたコマンドと、ルールを見比べる

ターミナル版では、/permissions と入力すると、すべてのルールと、それぞれが書かれているファイルを、一覧で見られます。

利用者の側では、減らせない場合

次の場合は、設定を変えても、確認は減りません。

起きていること	理由
`.git` や `.claude` の中への書き込みで、確認が出る	保護されたパスへの書き込みは、allow ルールでは、あらかじめ許可できない（下の「どの設定にしても、確認が残る操作」を参照）
Auto を選べない	モデルが対応していない。または、組織の管理設定で、無効になっている（下の「組織の設定による制限」を参照）

確認を減らす 3 つの方法の、選び方

利用者が確認を減らす方法は、大きく 3 つあります。安全さと手間のつり合いが、それぞれ違います。

方法	確認の減り方	気をつける点
allow ルールを足していく	許可したコマンドだけ、出なくなる	何を許可したかが、はっきりしている。`*` を広く書きすぎない
Accept edits にする	ファイルの編集で、出なくなる	コマンドの確認は残る。変更内容は、あとで差分を確認する
Auto にする	日常的な確認が、ほぼ出なくなる	分類器の審査は、安全の保証ではない。方向性を信頼できる作業に使う

これらは、組み合わせて使えます。たとえば、「Accept edits にして、ビルドとテストのコマンドだけを allow ルールに書き、git push は ask ルールにして毎回確認する」という設定ができます。外部に影響する操作（公開、送信、削除など）は、確認を残しておくのが安全です。

どの設定にしても、確認が残る操作

次の操作は、どのモードでも、自動では許可されません。

ask ルールに当てはまる操作：auto モードでも、確認が出る。
保護されたパスへの書き込み：.git、.vscode、.claude などへの書き込みは、Manual と Accept edits では確認が出て、Auto では分類器の審査に回る。allow ルールでは、あらかじめ許可できない。リポジトリの状態や、Claude 自身の設定を、誤って壊さないための仕組み。
利用者への質問：Claude が、選択肢を示して利用者に尋ねる操作は、確認そのものが目的なので、省略されない。
重要なパスの削除：rm -rf / や rm -rf ~ のような削除は、allow ルールでは許可されない。

組織の設定による制限

組織で Claude Code を使う場合、管理者が、管理設定を配布していることがあります。配布の方法は、PC の中に置く設定ファイル、端末を管理する仕組み、管理者用の画面からの配信など、いくつかあります。管理設定は、利用者やプロジェクトの設定より優先され、上書きできません。権限に関係するものには、次のような設定があります。

管理設定の項目	働き
`permissions.disableAutoMode`	auto モードを使えなくする
`permissions.disableBypassPermissionsMode`	bypassPermissions モードを使えなくする
`permissions.defaultMode`	始まるときのモードを指定する
`allowManagedPermissionRulesOnly`	権限ルールを、管理設定に書かれたものだけにする。利用者やプロジェクトが書いたルールは、使われなくなる
管理設定の中の deny ルール	どの設定でも、上書きできない

自分で設定を変えても確認が減らないときは、管理設定で制限されている可能性があります。その場合は、利用者の側では変えられないので、管理者に確認します。

Claude のコマンドが、PC の上でできること

ここまでの権限モードと権限ルールは、操作の前に、実行してよいかを決める仕組みです。では、実行を認めたコマンドは、PC の上で何をできるのでしょうか。

何もしなければ、利用者と同じ力で動く

Claude が実行するコマンドは、Claude Code を動かしている利用者のユーザーと同じ権限で動きます。公式ドキュメント（Security）は、権限の確認は「尋ねるだけの仕組み」で、認めたコマンドは利用者が書き込める場所なら、どこにでも書き込めると説明しています。

このため、「Claude がソフトウェアを入れられるか」は、次の条件で決まります。

条件	例	入れられるか
利用者のユーザーで書き込める場所か	プロジェクトの中の仮想環境（Python の `venv/` など）、ホームフォルダーの中	入れられる
	利用者が持ち主になっている場所（Homebrew の置き場所など）	入れられる（このサイトでは確かめていない）
管理者のパスワードが必要な場所か	macOS のシステムの場所	入れられない。パスワードの入力は、Claude には任せない
途中で、利用者にしかできない操作が入るか	サインイン、macOS の許可の画面	最後まではできない。利用者の操作が必要

技術的に入れられることと、入れてよいことは別です。このサイトでは、Claude が何かを入れる前に、何を、どこに、どれくらいの大きさで入れ、失敗したら何が残るかを伝えて、承認を得ることにしています。

守りの仕組みは 3 層ある

公式ドキュメントでは、Claude の操作を制限する仕組みを、次の 3 つに分けて説明しています。

層	何をするか	既定
1. 権限（このページの前半）	操作の前に、尋ねる、許可する、禁止する	動いている
2. サンドボックス	Claude が実行するコマンドを、OS の仕組みで囲う	無効
3. 隔離された環境	Claude Code 全体を、コンテナや仮想マシンなど、PC から切り離した場所で動かす	使っていなければ、なし

1 の権限は、Claude Code が「実行してよいか」を判断する仕組みです。auto モードの分類器も、この層に入ります。分類器が見ているのは、実行しようとしているコマンドです。そのコマンドが呼び出すプログラムの中身までは、見ていません。

2 のサンドボックスは、実行中のコマンドに、OS が制限をかけます。コマンドが呼び出したプログラムにも、同じ制限がかかります。

サンドボックスが制限すること

種類	有効にしたときの既定	変える設定
書き込み	作業フォルダー、一時フォルダー、追加した作業フォルダーだけ。その中でも、Claude Code の設定ファイル（`.claude` の設定、`.mcp.json`、`.git` の `hooks` と `config` など）には書き込めない	`sandbox.filesystem.allowWrite`、`denyWrite`
読み取り	PC のほとんどを読める。`~/.ssh` のような認証情報のファイルも含む	`sandbox.filesystem.denyRead`
通信	許可した相手（`sandbox.network.allowedDomains`）だけ。それ以外の相手にどうするかは、権限モードで変わる（下の表）	`sandbox.network.allowedDomains`、`deniedDomains`

許可していない相手につなごうとしたときの動きは、権限モードによって違います。

権限モード	許可していない相手への接続
Manual、Accept edits、Plan	利用者に確認が出る
Auto	断られる。ただし、Claude がそのコマンドに通信先の一覧を付けて、分類器がそれを認めた場合は、そのコマンドの間だけ通る
bypassPermissions	確認なしで通る

設定ファイルに設定するときは、次のように書きます。プロジェクトの .claude/settings.local.json に書くと、そのプロジェクトで、自分だけに効きます。

json

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "pypi.org"]
    }
  }
}

ターミナル版では、/sandbox のコマンドからも設定できます。元に戻すときは、"sandbox" のまとまりを削除します。

サンドボックスが制限しないこと

公式ドキュメントは、次のものはサンドボックスの外で、利用者と同じ力のまま動くと説明しています。

Claude がファイルを読み書きする道具（Read、Edit、Write）と、Web ページを取得する道具
フック（「09. Hooks」）、ローカルの MCP サーバー（「07. MCP とコネクター」）
利用者が設定で外に出したコマンド（sandbox.excludedCommands）
サンドボックスに止められたあと、Claude が「サンドボックスの外で実行し直したい」と求め、それが認められたコマンド。auto モードでは、分類器が判断する

また、公式ドキュメントは、サンドボックスは危険を減らすが、完全な隔離ではない、としています。

サンドボックスで、確認を減らすこともできる

サンドボックスを有効にすると、既定では、サンドボックスの中で動くコマンドは、確認なしで実行されます（sandbox.autoAllowBashIfSandboxed）。OS が制限をかけているので、1 つずつ確認しなくてよい、という考え方です。

公式ドキュメントの使い方の手引き（Best practices）は、自分の PC で確認を減らしたいときの方法として、信頼できる道具を allow ルールに入れることと、サンドボックスを有効にすることを挙げています。Manual で確認が多いと感じている場合は、auto モードとは別の選択肢になります。

実際にやってみる

このサイトの作業で使っているセッションが、どの設定で動いているかを確かめました。

今のセッションの権限モードを確かめる

デスクトップアプリが Claude Code を起動するときの指定は、実行中のプロセスの一覧で見られます。

bash

ps -axo command | grep 'claude-code' | grep -o -- '--permission-mode=[a-z]*'

結果は、次のとおりでした。

text

--permission-mode=auto

このセッションは、auto モードで始まっていました。

権限ルールが、どこかに書かれているかを確かめる

権限ルールが書かれる場所を、順に確かめました。

場所	役割	結果
`~/.claude/settings.json`	利用者ごとの設定	ファイルがない
プロジェクトの `.claude/settings.json`	プロジェクトで共有する設定	ファイルがない
プロジェクトの `.claude/settings.local.json`	自分だけの設定。「今後は確認しない」の保存先	ファイルがない

利用者とプロジェクトの設定には、権限ルールは 1 つも書かれていませんでした。

分かったこと

このサイトでは、ページを書く、ビルドする、コミットする、公開する、という作業を、確認がほとんど出ない状態で進めています。その理由は、allow ルールを書いているからではなく、auto モードで動いているからでした。

このことから、確認の出方が環境によって違うときに、最初に確かめることが分かります。

そのセッションが、どの権限モードで動いているか
権限ルールが、どのファイルに、何と書かれているか
管理設定があるか

サンドボックスの状態を確かめる

このサイトの作業で、Claude のコマンドがどこまでできる状態だったかを確かめました。

確かめたこと	結果
サンドボックスの設定（利用者、プロジェクト、管理設定）	どこにもない。既定の無効のまま
コマンドを動かしているユーザー	利用者自身のユーザー。このユーザーは、Mac の管理者のグループに入っている
作業フォルダーの外（ホームフォルダー）への書き込み	書き込めた（試しのファイルは、すぐ消した）

つまり、このサイトの作業では、auto モードの分類器の審査だけを守りにして、Claude のコマンドが利用者とほぼ同じ力で動いていました。公式ドキュメントが自分の PC で勧めている、サンドボックスと組み合わせる形ではありませんでした。

サンドボックスを、このサイトだけで有効にして試す

このサイトのプロジェクトの .claude/settings.local.json に、次の設定を足して試しました。通信先には、GitHub、Python の部品の取得先、npm の取得先を許可しました。権限モードは Auto のままです。

json

"sandbox": {
  "enabled": true,
  "network": {
    "allowedDomains": [
      "github.com",
      "api.github.com",
      "pypi.org",
      "files.pythonhosted.org",
      "registry.npmjs.org"
    ]
  }
}

デスクトップアプリでも、設定を足したあとの次のコマンドから、サンドボックスが効きました。結果は、次のとおりです。

試したこと	期待したこと（根拠）	結果	期待と違った点と、その理由
作業フォルダーの外（ホームフォルダー）にファイルを書く	止められる（書き込みの制限）	止められた（`operation not permitted`）	—
サイトのビルド（`npm run docs:build`）	通る（作業フォルダーの中で完結する）	通った	—
許可していない相手（`example.com`）につなぐ	止められる（通信の制限）	つながった	理由は分かっていない。公式ドキュメントでは、Auto で許可していない相手に通るのは、Claude がコマンドに通信先の一覧を付けて、分類器が認めた場合だけ。今回、Claude はその一覧を付けていない
`git fetch` で、GitHub への認証が通るかを見る	認証が通るか分かる	通ったが、認証は確かめられていない	このサイトのリポジトリは公開されているので、`git fetch` は認証を使わない。認証を使う `git push` は試していない
`gh`（GitHub の操作をするコマンド）	失敗するかもしれない（公式ドキュメントに、macOS で証明書の検証に失敗することがある、とある）	失敗した（`x509: OSStatus -26276`）	—
Bash のコマンドで、ポートを開く	—	止められた（`Operation not permitted`）	公式ドキュメントでは、macOS では既定でポートを開けない（`sandbox.network.allowLocalBinding` で許可できる）
確認用のサーバーを、Claude のプレビューの道具で起動する	—	起動できた	Bash のコマンドではないので、サンドボックスの外で動いたと考えられる
プロセスの一覧を見る（上の「今のセッションの権限モードを確かめる」の `ps`）	—	止められた（`operation not permitted`）	—

gh が失敗したとき、gh は「キーチェーンのトークンが無効」と表示しました。実際の原因は証明書の検証の失敗で、トークンは壊れていません。

分かったことと、このサイトでの判断

確かに働いたのは、作業フォルダーの外への書き込みを止めることでした。通信の制限は、許可していない相手につながった理由が分かっていないので、どこまで働くかを確かめられていません。

一方で、プルリクエストの作成やマージに毎日使っている gh が、動かなくなりました。公式ドキュメントは、gh を sandbox.excludedCommands に入れてサンドボックスの外で動かす方法を案内しています。しかし、これはサンドボックスに穴を開けることになります。公式ドキュメント自身も、外に出す設定は便利のためのもので、守りではないとしています。

このサイト（macOS、auto モード、gh を毎日使う）では、得られる守りに対して代償が大きいので、サンドボックスは有効にしないことにしました。設定は、"sandbox" のまとまりを削除して、元に戻しました。

サンドボックスが役に立つと考えられるのは、たとえば次の場合です。どちらも、このサイトでは試していません。

Manual で、確認が多いと感じている場合：サンドボックスの中のコマンドが確認なしで動くので、auto モードを使わずに確認を減らせる。
macOS 以外（Linux や WSL2）の場合：gh の証明書の検証の失敗は、macOS のサンドボックスの仕組みで起きると、公式ドキュメントに書かれている。

まとめ

確認が出るかどうかは、操作の種類、権限モード、権限ルールの 3 つで決まる。
読み取りと、読み取り専用のコマンドは、確認なしで実行される。ファイルの変更と、それ以外のコマンドは、Manual では確認が出る。
権限モードは 6 つある。普段の作業で確認を減らすために使うのは、Accept edits と Auto。bypassPermissions は、切り離された環境だけで使う。
権限ルールは、deny、ask、allow の順に調べられる。deny は、ほかの設定では上書きできない。確実に止めたい操作は、指示ではなく、deny ルールに書く。
確認が多いときは、どの種類の操作で出ているかを見て、モードの変更、allow ルールの追加、作業フォルダーの追加のどれが合うかを選ぶ。
保護されたパスへの書き込みなど、どの設定でも確認が残る操作がある。組織の管理設定で、制限されていることもある。
権限は、実行の前に判断する仕組み。実行を認めたコマンドは、利用者と同じ力で動く。それを OS の仕組みで制限するのが、サンドボックス。既定では無効。
このサイトで試すと、作業フォルダーの外への書き込みは止められたが、gh が動かなくなった。代償が大きいので、このサイトでは有効にしなかった。

確認の記録

項目	内容
最終確認日	2026 年 10 月 12 日（サンドボックスの節は 2026 年 10 月 22 日）
Claude Code のバージョン	2.1.295（macOS のデスクトップアプリ）。サンドボックスの節は 2.1.304（同じデスクトップアプリ）
検証の状況	「実際にやってみる」は、macOS のデスクトップアプリと、このサイトのリポジトリで確かめた結果。それ以外の節は、公式ドキュメントの内容をもとに書いている
確かめていない内容	権限モードの切り替え、権限ルールの追加、「今後は確認しない」での保存、作業フォルダーの追加は、実際には操作していない。ターミナル版と VS Code の拡張機能での動きも、公式ドキュメントの説明をもとに書いている。サンドボックスについては、Manual での確認の減り方、`sandbox.excludedCommands` と `allowLocalBinding` の設定、`git push`、許可していない相手につながった理由を確かめていない

分野 3：Claude Code の設定と使い方

権限モードと、確認を減らす方法 ​

この記事で分かること ​

用語の整理 ​

確認が出る仕組み ​

読み取り専用のコマンド ​

権限モード ​

acceptEdits：ファイルの編集は確認しない ​

plan：調べて、計画を立てるだけ ​

auto：分類器が、利用者の代わりに審査する ​

bypassPermissions：確認を行わない ​

モードの切り替え方と、始まるときのモード ​

権限ルール ​

評価の順番 ​

書き方 ​

確認の画面からルールを保存する ​

作業フォルダー ​

Claude が確認を求める回数が多いとき、利用者ができること ​

ファイルを編集するたびに、確認が出る ​

同じコマンドを実行するたびに、確認が出る ​

どのコマンドでも、確認が出る ​

作業フォルダーの外のファイルを読むときに、確認が出る ​

新しいセッションを始めるたびに、Manual に戻っている ​

allow ルールを書いたのに、確認が出る ​

利用者の側では、減らせない場合 ​

確認を減らす 3 つの方法の、選び方 ​

どの設定にしても、確認が残る操作 ​

組織の設定による制限 ​

Claude のコマンドが、PC の上でできること ​

何もしなければ、利用者と同じ力で動く ​

守りの仕組みは 3 層ある ​

サンドボックスが制限すること ​

サンドボックスが制限しないこと ​

サンドボックスで、確認を減らすこともできる ​

実際にやってみる ​

今のセッションの権限モードを確かめる ​

権限ルールが、どこかに書かれているかを確かめる ​

分かったこと ​

サンドボックスの状態を確かめる ​

サンドボックスを、このサイトだけで有効にして試す ​

分かったことと、このサイトでの判断 ​

まとめ ​

確認の記録 ​

権限モードと、確認を減らす方法

この記事で分かること

用語の整理

確認が出る仕組み

読み取り専用のコマンド

権限モード

acceptEdits：ファイルの編集は確認しない

plan：調べて、計画を立てるだけ

auto：分類器が、利用者の代わりに審査する

bypassPermissions：確認を行わない

モードの切り替え方と、始まるときのモード

権限ルール

評価の順番

書き方

確認の画面からルールを保存する

作業フォルダー

Claude が確認を求める回数が多いとき、利用者ができること

ファイルを編集するたびに、確認が出る

同じコマンドを実行するたびに、確認が出る

どのコマンドでも、確認が出る

作業フォルダーの外のファイルを読むときに、確認が出る

新しいセッションを始めるたびに、Manual に戻っている

allow ルールを書いたのに、確認が出る

利用者の側では、減らせない場合

確認を減らす 3 つの方法の、選び方

どの設定にしても、確認が残る操作

組織の設定による制限

Claude のコマンドが、PC の上でできること

何もしなければ、利用者と同じ力で動く

守りの仕組みは 3 層ある

サンドボックスが制限すること

サンドボックスが制限しないこと

サンドボックスで、確認を減らすこともできる

実際にやってみる

今のセッションの権限モードを確かめる

権限ルールが、どこかに書かれているかを確かめる

分かったこと

サンドボックスの状態を確かめる

サンドボックスを、このサイトだけで有効にして試す

分かったことと、このサイトでの判断

まとめ

確認の記録