3行でいうと

  • 確認の基準は「承認モード」で決まります。公式の設定値は default（変更や実行は毎回確認）、auto_edit（編集は自動承認）、plan（読むだけ）で、すべて自動承認の yolo は、設定ファイルでは選べず、起動の旗か、ショートカットで入る形です。
  • 「信頼するフォルダ（Trusted Folders）」は、プロジェクトに入っている設定やコマンド、MCPサーバー、フックを、読み込んでよいかを聞く仕組みです。信頼しないフォルダでは、プロジェクトの .gemini/settings.json も、MCPサーバーも、無視されます。ただし、この機能が最初から有効かどうかは、公式の2つのページで書き方が違います（本文の「気をつけること」）。
  • サンドボックスは、コマンドを囲いの中で動かす仕組みです。公式は、macOSのSeatbelt、DockerやPodman、gVisor（runsc）、LXC（実験的）、Windows用を挙げています。ただし公式は、リスクを減らすが、なくすものではない、と書いています。
  • 許可と拒否のルールは「ポリシーエンジン」のTOMLに書きます。公式は、拒否には tools.exclude より deny ルールを使うよう案内し、tools.exclude と --allowed-tools と --yolo の旗には「非推奨」の表記があります。

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はGeminiを入れていますが、使い心地はこの記事には書いていません。設定のキー、コマンド、旗、TOMLやJSONの例は、公式に書かれたとおりに写したか、公式の表の項目を組み合わせた形で、動作確認はしていません（組み合わせた例は、そのつど断ります）。公式ページは要約の形で取得したため、読み切れていない箇所があります。公式の2つのページで書き方がずれているところは、ずれたまま書いて、確かめられなかった、と添えました。Gemini CLIの導入やGEMINI.md、MCP、Extensionsなどは、前のガイド（04）に書いたので、ここでは「許可と囲い」に絞ります。

先に結論

前提：用語をそろえる

承認モード：4つのモードと、切り替え方

公式の「CLI参照」「設定リファレンス」「Plan Mode」「キーボードショートカット」のページを突き合わせた表です（確認日10月24日）。

モード 動き 入り方 公式のどこに書かれているか
default 標準。ほとんどの書き込み系ツールは確認が出る 既定値 設定リファレンス、ポリシーエンジン
auto_edit 編集ツールを自動承認 設定 general.defaultApprovalMode、--approval-mode=auto_edit、Shift+Tab 設定リファレンス、CLI参照
plan 読むだけ。計画をmdで書いてから承認を求める --approval-mode=plan、/plan、Shift+Tab、設定 Plan Modeのページ
yolo すべて自動承認 --approval-mode=yolo（--yolo は非推奨）、ショートカット Ctrl+Y で切り替え CLI参照、キーボードショートカット

綴りに注意が要ります。設定ファイルと --approval-mode では auto_edit ですが、ポリシーエンジンのページでは、モード名を autoEdit（modes = ["default", "autoEdit"] など）と書いています。公式の2つのページで綴りが違うので、ポリシーに書くときは、そのページの綴りに従い、うまくいかないときは /policies list で、有効なポリシーがモード別に並ぶか確かめる、という手があります（これは僕らの手順の提案で、公式にそう書いてあるわけではありません）。

切り替え。 Shift+Tab は、default、auto_edit、plan を順に回ります。Planは、処理中や確認画面が出ている間は飛ばされる、とあります。Ctrl+Y は、YOLOの入り切りのショートカットとして、ショートカット一覧に載っています。公式のショートカットの表では、Windows Terminalで、Node 20以前と一部のNode 22では Shift+Tab が使えない、とも書かれています。

YOLOは設定では入れません。 設定リファレンスの general.defaultApprovalMode は、値が default、auto_edit、plan の3つで、YOLOは、起動の旗の --yolo か --approval-mode=yolo でだけ有効にできる、と書かれています。YOLOを禁止したいときは security.disableYoloMode（既定 false）が使えます。旗で指定しても、無効にできる、と書かれています。なお --yolo の旗そのものは、CLI参照で「非推奨」とされ、--approval-mode=yolo に置き換えるよう案内されています。

ツールごとの確認：どれが止まるか

公式のツール一覧では、run_shell_command（コマンドの実行）、write_file（作成・上書き）、replace（部分的な書き換え）が「確認が必要」です。ファイルの読み取りや検索のツールには、確認の要否が書かれていません（読めた範囲では見つからなかった、という意味です）。web_fetch は、確認が要るのは「Plan Modeのとき」と表にあります。公式は、ファイルを変えるもの、シェルを動かすものは、手で承認する、確認画面ではdiffや実行されるコマンドそのものが出るので、よく読んで許可するように、と書いています。

シェルコマンドの確認画面の選択肢は、公式のシェルコマンドの手引きでは、Allow once（今回だけ）、Allow always（そのコマンドを、そのセッションの間は信頼する）、Deny（拒否してエージェントを止める）の3つです。「Allow always」の効き目はセッションの間で、その手引きには、永続的な許可の案内はありません。ただし設定リファレンスには、確認画面に「Allow for all future sessions（今後のセッションすべてで許可）」の選択肢を出すための security.enablePermanentToolApproval（既定 false）があります。つまり、永続の許可は、既定では選択肢に出ず、設定で出すものだと読めます。

「Allow for all future sessions」の効き方（ポリシーのページの記載）

公式のポリシーエンジンのページは、永続の承認を「モードを意識したもの」と説明しています。モードの強さを plan < default < auto_edit < yolo と並べ、default で承認すると、default、auto_edit、yolo に効きます。auto_edit で承認すると auto_edit と yolo、yolo で承認すると yolo だけです。plan で承認すると4つすべてに効きます。Plan Modeのページにも、同じ向きの記載があります（DefaultやAuto-Editでの承認は、Planには及ばない）。ほかに、security.disableAlwaysAllow（既定 false）で「Always allow」の選択肢を消す設定と、security.autoAddToPolicyByDefault（既定 false）で、信頼されたワークスペースの低リスクのツールについて、この選択肢を既定にする設定があります。承認の保存先のファイル名は、読んだ公式のdocsには見つかりませんでした。

信頼するフォルダ（Trusted Folders）

公式の「Trusted Folders」のページは、これを、どのプロジェクトにGemini CLIの能力をフルに使わせるかを決める、セキュリティの設定だと説明しています。プロジェクト固有の設定を読み込む前に、そのフォルダの承認を求め、悪意のあるコードを避ける狙いです。

有効にする設定

公式の例は、ユーザーの settings.json に、次のように書く形です。

{
  "security": {
    "folderTrust": {
      "enabled": true
    }
  }
}

信頼ダイアログ

有効にすると、そのフォルダで最初に起動したときに、ダイアログが出ます。選択肢は次の3つです。

答えは ~/.gemini/trustedFolders.json に保存されます。決める前に、CLIはそのフォルダを調べて、カスタムコマンド（.toml）、MCPサーバー、フック、スキル、グローバルの設定を上書きする設定を、ダイアログに一覧で出します。自動承認や、サンドボックスの無効化などの警告や、設定ファイルの形式の誤りも出る、と書かれています。知らないリポジトリを開くときは、この一覧が、何が動き出すかを確かめる機会になる、というのは僕らの見立てです。

信頼しないフォルダでは、何が止まるか

公式は、7つを挙げています。

  1. プロジェクトの .gemini/settings.json を無視する
  2. プロジェクトの .env を読まない
  3. 拡張機能のインストール、更新、削除を止める
  4. ツールの自動承認をやめ、毎回確認する（全体で自動承認にしていても）
  5. ローカルの設定が指すディレクトリの記憶（メモリ）を、自動で読み込まない
  6. MCPサーバーに接続しない
  7. カスタムの .toml コマンド（プロジェクト用もグローバル用も）を読み込まない

管理するコマンド

信頼の判定の順番

公式のページでは、①IDEと連携しているなら、IDEの信頼の答えが最優先、②IDEがなければ ~/.gemini/trustedFolders.json を見る、の順です。

自動化（CIなど）での扱い

公式は、対話できない環境（CI/CDなど）ではダイアログを出せないので、機能が有効なのに、フォルダが未信頼だと、FatalUntrustedWorkspaceError で終了する、と書いています。回避は、旗の --skip-trust か、環境変数 GEMINI_CLI_TRUST_WORKSPACE=true です。どちらも、そのセッションに限って、今のワークスペースを信頼します。設定リファレンスは、後者を、ヘッドレス環境（CI/CD）向けに案内しています。これは、自分が中身を管理しているリポジトリだけで使うものだ、というのは僕らの見立てです。

サンドボックス：コマンドを囲いの中で動かす

公式の「Sandboxing」のページを写します（確認日10月24日）。まず前提として、公式はCLIをnpmで入れる前提で書いています（npm install -g @google/gemini-cli、gemini --version で確認）。

有効にする3つの方法

優先順位の高い順に、次の3つです。

  1. 旗：-s または --sandbox
  2. 環境変数：GEMINI_SANDBOX=true|docker|podman|sandbox-exec|runsc|lxc
  3. 設定ファイル：tools の中の "sandbox": true

公式の例は次のとおりです。

gemini -s -p "analyze the code structure"

export GEMINI_SANDBOX=true
gemini -p "run the test suite"

{
  "tools": {
    "sandbox": "docker"
  }
}

方式の比較

方式 対象のOS 公式の説明の要点 注意（公式の記載）
macOS Seatbelt macOSのみ sandbox-exec による、軽量の組み込み方式。既定のプロファイルは permissive-open プロファイルは環境変数 SEATBELT_PROFILE で選ぶ
Docker / Podman 各OS 完全なプロセスの隔離。既定の画像は ghcr.io/google/gemini-cli:latest DockerかPodmanが起動している必要がある。作業フォルダは、同じ絶対パスでコンテナに入る
Windows 標準 Windowsのみ icacls で、書き込みが要るファイルやフォルダに「Low Mandatory Level」を付ける この設定は、セッションが終わっても残る。元に戻す手順が載っている
gVisor（runsc） Linuxのみ ユーザー空間のカーネルで、最も強い隔離と書かれている 自動検出されない。GEMINI_SANDBOX=runsc か sandbox: "runsc" で、明示する
LXC / LXD Linuxのみ（実験的） systemd などが動く、システム全体のコンテナ コンテナを自分で作り、起動しておく。CLIは作らない

macOS Seatbeltのプロファイル。 公式の表では、permissive-open（既定。書き込みを制限、ネットワークは許可）、permissive-proxied（書き込みを制限、ネットワークはプロキシ経由）、restrictive-open（厳しい制限、ネットワークは許可）、restrictive-proxied（厳しい制限、プロキシ経由）、strict-open（読み書きとも制限、ネットワークは許可）、strict-proxied（読み書きとも制限、プロキシ経由）の6つです。既定の permissive-open は、書き込みをプロジェクトのフォルダに限り、読み取りとネットワークは広く許す、と書かれています。つまり既定のままだと、ネットワークには出られます。

Dockerの画像を変える。 設定で、次のように、オブジェクトで書けます（公式の例）。

{
  "tools": {
    "sandbox": {
      "command": "docker",
      "image": "us-central1-docker.pkg.dev/my-project/my-repo/my-custom-sandbox:latest"
    }
  }
}

環境変数 GEMINI_SANDBOX_IMAGE でも指定できます。画像には bash などの標準的なシェルの道具が要る、とあります。プロジェクトに .gemini/sandbox.Dockerfile を置いて、BUILD_SANDBOX=1 GEMINI_SANDBOX=docker gemini -p "..." とすると、その場でビルドする方法も載っていますが、自動のビルドは、ソースから動かすときだけで、npmで入れた場合は、ビルド済みの画像が要る、と書かれています。

囲いの中に外のファイルを入れる、通す

ツール単位のサンドボックスと、拡張の確認画面

公式のページには、CLIのプロセス全体ではなく、個々のツールの実行（shell_exec、write_file など）を隔離する「Tool Sandboxing」の説明があり、設定は security.toolSandboxing（既定 false、再起動が必要）です。ページには、これを無効にする書き方が載っていて、既定との関係の説明は、読めた範囲では詳しく書かれていませんでした。設定リファレンスの表は、tools.sandbox を「レガシーの全体のサンドボックス」と呼んでいます。一方、Sandboxingのページは tools.sandbox を、有効にする普通の方法として案内しています。この呼び方のずれは、確かめきれませんでした。

囲いの中のコマンドが、権限の制限（制限されたパスやネットワーク）で失敗したとき、あるいは npm install のように、事前に追加の権限が要ると分かったとき、CLIは「Sandbox Expansion Request」の画面を出します。承認すると、その1回だけ、広い権限で実行されます。

Docker内でGemini CLIを動かすとき、よくあるつまずき（公式の記載と、僕らの見立て）
  • Gemini CLI自体をDockerのコンテナの中で動かす場合、ホストのDockerのソケット（/var/run/docker.sock）をマウントして、CLIが兄弟のサンドボックスのコンテナを作れるようにします。その場合、作業フォルダのパスは、ホストの絶対パスと完全に同じにします（ボリュームのマウントがホスト側で解決されるため）。公式のページには、ソケットのマウントに関する注意書きは見つかりませんでした。ソケットをマウントすると、そのコンテナがホストのDockerを操作できるようになる、というのは僕らの見立てです。
  • 「Operation not permitted」と出たら、囲いの外のものに触ろうとしている状態です。より緩いプロファイルにするか、マウントを足します。コマンドが足りないときは、Dockerfileに足すか、sandbox.bashrc で入れる、とあります（sandbox.bashrc の置き場所などは、読んだページに詳しい説明がありませんでした）。ネットワークの問題は、プロファイルがネットワークを許しているか、プロキシの設定を確かめます。

公式の警告。 サンドボックスは、リスクを減らしますが、なくしません。作業に足りる中で、一番厳しいプロファイルを使う。GUIのアプリは、中では動かないことがある、と書かれています。シェルの手引きは、信頼できないコードや新しいプロジェクトでは、まず gemini --sandbox で始めることを強く勧めています。

ポリシーエンジン：許可と拒否のルールを、TOMLに書く

公式のポリシーエンジンのページを整理します。ここがGemini CLIの「許可のルール」の中心です。

置き場所と読み込み

ユーザーのポリシーは、~/.gemini/policies を作り、その中の、拡張子が .toml のファイルです。複数あれば、まとめて読み込まれます。公式の最小の例は、toolName = "run_shell_command"、commandPrefix = "rm -rf"、decision = "deny"、priority = 100 の組です。Plan Modeのページに載っている書式にそろえると、次のようになります（フィールド名と値は公式のページのもの。ファイルの形は、Plan Modeのページの例にそろえた、僕らの組み合わせです）。

[[rule]]
toolName = "run_shell_command"
commandPrefix = "rm -rf"
decision = "deny"
priority = 100

ルールの条件と、決定

優先度のしくみ（4つの層）

最終の優先度は「層の基準値 + TOMLの priority（0〜999）÷ 1000」と書かれています。

層 基準値（公式の表） 備考
Default（組み込み） 1 組み込みのルール
Extension 2 拡張機能が持つルール
Workspace 3 公式が「現在は動かない」と書いている。プロジェクトの .gemini/policies は効かない
User 4 ~/.gemini/policies/*.toml
Admin 5 管理者が置く。Linuxは /etc/gemini-cli/policies、macOSは /Library/Application Support/GeminiCli/policies、Windowsは C:\ProgramData\gemini-cli\policies

ただし、このページの中に食い違いがあります。表ではUserの基準値が4、Adminが5ですが、同じページの例では「Userの priority: 100 が 3.100」「Adminの priority: 20 が 4.020」となっていて、Userが3、Adminが4に読めます。どちらが現行の実装かは、読んだ範囲では確かめきれませんでした。いずれにしても、層の順番（Default < Extension < Workspace < User < Admin）は、どの書き方でも同じです。つまり、ユーザーが書いたルールは、既定のルールに勝ち、管理者のルールは、ユーザーのルールに勝ちます。プロジェクトのポリシーは、今は動きません。リポジトリに入れたポリシーで、チームに強制することはできない、というのが、現状の公式の記載から読める点です（僕らの読みです）。

管理者用のポリシーには、追加の読み込み経路もあります。旗 --admin-policy、または、システムの設定ファイルの adminPolicyPaths です。ただし、標準のシステムの場所に .toml があると、これらは無視されます。標準のシステムの場所のポリシーは、Linux/macOSでは、rootの所有で、グループやその他に書き込み権限がないこと（chmod 755 など）、Windowsでは C:\ProgramData の下で、Users/Everyone に書き込み、変更、フルコントロールがないことが条件で、満たさないと、そのポリシーは無視される、と書かれています。なお、設定リファレンスには、ユーザー用の追加の読み込み先として policyPaths（追加のポリシーのファイルかディレクトリ、既定は空）がありますが、ポリシーエンジンのページには、--policy の旗も policyPaths も出てこず、CLI参照にも --policy はありませんでした。

管理者のポリシーを置く手順の例（僕らの並べ方です）。 公式の条件は、標準のシステムの場所に置くこと、rootの所有、グループとその他に書き込み権限がないこと、の3つです。Linuxなら、次の順になります。コマンドは条件を並べ直したもので、動作確認はしていません。権限が条件に合わないと、そのポリシーは無視されると書かれているので、最後の確認が大事です。

sudo mkdir -p /etc/gemini-cli/policies
sudo cp my-rules.toml /etc/gemini-cli/policies/
sudo chown -R root:root /etc/gemini-cli/policies
sudo chmod -R 755 /etc/gemini-cli/policies
ls -l /etc/gemini-cli/policies

置いたあとは、Gemini CLIを起動して /policies list で、そのルールが一覧に出るかを見ます（/policies list を使うのは僕らの提案です）。出なければ、まず所有者と権限を疑います。

シェルコマンドのルール

公式の例は、commandPrefix = "git"、decision = "ask_user"、priority = 100 で、gitのコマンドは、毎回確認する、という形です。

対話しない実行（-p など）で、特定のコマンドだけを通したいときの形も、公式のフィールドで組めます。interactive = false は「対話でないときだけ」効く条件で、ask_user が deny 扱いになる場面に、allow を足す使い方です。次は、公式の項目を組み合わせたこの記事の例で、動作確認はしていません。

[[rule]]
toolName = "run_shell_command"
commandPrefix = "npm test"
decision = "allow"
priority = 100
interactive = false

commandPrefix は前方一致なので、npm test で始まる別のコマンドも通ります。通す範囲は、できるだけ狭く書いてください。

MCPのルール

公式が推すのは mcpName を使う書き方です。特定のツールは mcpName と、mcp_ 抜きの簡単な toolName（たとえば search）の組、サーバーの全部は mcpName だけ、全サーバーは toolName = "*" と mcpName = "*" の組です。公式の例は、untrusted-server を deny（優先度500）にし、denyMessage を付ける形です。警告：MCPサーバーの名前にアンダースコアを使わない（my-server はよい、my_server はだめ）。名前は、mcp_ の後の最初のアンダースコアで分けて解釈されるので、ワイルドカードや安全のためのルールが、気づかないうちに効かなくなることがある、と書かれています。

[[rule]]
mcpName = "untrusted-server"
decision = "deny"
priority = 500
denyMessage = "このサーバーは使わない"

上のTOMLは、公式の例のフィールドと値を並べ直したもので、denyMessage の文面は僕らが付けた仮のものです。なお、ポリシーエンジンのページには、フィールドの説明は denyMessage、サブエージェントの例は deny_message と、綴りが違う書き方が見つかりました。どちらが正しいかは確かめられなかったので、denyMessage を使うなら、/policies list などで、拒否のメッセージが出るかを、最初に確かめておくのが無難です（これは僕らの提案です）。

組み込みの既定のポリシー

公式の記載の範囲では、読み取りのツール（read_file、glob など）は、おおむね許可、エージェントへの委任は ask_user、書き込み系（write_file、run_shell_command）も ask_user です。yolo では、優先度の高いルールがすべてのツールを許可します。auto_edit では、一部の書き込みが、確認なしで通ります。組み込みの既定のファイルの名前や中身は、ポリシーエンジンのページには出てきませんでした（Plan Modeのページに、組み込みの制限は plan.toml にある、と書かれています）。

モードで、ルールを分ける

Plan Modeのページに、公式の例があります。次のルールは、modes に plan を入れないことで、Plan Modeでは効かなくなります（例は公式のもの）。

[[rule]]
toolName = "run_shell_command"
commandPrefix = "npm test"
decision = "allow"
priority = 100
modes = ["default", "autoEdit"]

反対に、Plan Modeだけで、読み取り専用のMCPツールを許す例は、次のとおりです（公式のもの）。

[[rule]]
toolName = "*"
mcpName = "*"
toolAnnotations = { readOnlyHint = true }
decision = "allow"
priority = 100
modes = ["plan"]

modes を書かないルールは、Plan Modeも含めて、いつでも有効です。

古い書き方：tools.core、tools.allowed、tools.exclude

設定ファイルには、ポリシーより前からある、ツールの許可と拒否の項目が残っています。公式の設定リファレンスの表（確認日10月24日）です。

項目 意味（公式の表） 状態
tools.allowed 確認ダイアログを飛ばすツール名。たとえば run_shell_command(git) 再起動が必要。説明は「確認を飛ばす」
tools.core 組み込みのツールを、列挙したものだけに制限する許可リスト 再起動が必要。シェルだけでなく、組み込みのツール全体に効く
tools.confirmationRequired 常に確認を求めるツール。許可リストより優先 再起動が必要
tools.exclude 探索から除外するツール シェルの手引きでは「非推奨」。ポリシーの deny を勧める

シェルの手引きの規則は次のとおりです。つないだコマンド（&&、||、;）は分けて、それぞれ確かめ、1つでも不許可なら全体がブロックされます。許可は前方一致で、git を許すと git status や git log も通ります。tools.exclude が先に確かめられるので、両方に入っていればブロックされます。例は、git と npm だけ許す "tools": {"core": ["run_shell_command(git)", "run_shell_command(npm)"]} で、ls -l はブロックされます。

注意が要る点が2つあります。①tools.core は、組み込みのツール全体の許可リストなので、run_shell_command(...) だけ書くと、ほかの組み込みのツール（ファイル編集など）も、リストから漏れて使えなくなる、と公式は警告しています。②Enterpriseのページの例は、ReadFileTool、GlobTool、ShellTool(ls) と、ツール名が、今のツール一覧の read_file、glob、run_shell_command と違う書き方でした。どの名前が今の版で効くかは、読んだ範囲では確かめきれませんでした。新しく書くなら、今のツール一覧の名前を使い、ポリシーのTOMLで書くほうが、公式の案内に沿います。

settings.jsonの優先順位と置き場所

公式の設定リファレンスでは、設定は、優先度の低いものから、次の7層で、上の層が下を上書きします。

順番 層 場所 備考
1（弱い） 既定値 アプリに組み込み
2 システムの既定値ファイル /etc/gemini-cli/system-defaults.json（Linux）、C:\ProgramData\gemini-cli\system-defaults.json（Windows）、/Library/Application Support/GeminiCli/system-defaults.json（macOS） 場所は環境変数 GEMINI_CLI_SYSTEM_DEFAULTS_PATH で変えられる
3 ユーザーの設定 ~/.gemini/settings.json 全OS同じ
4 プロジェクトの設定 プロジェクトの .gemini/settings.json 信頼しないフォルダでは無視される
5 システムの設定 /etc/gemini-cli/settings.json（Linux）、C:\ProgramData\gemini-cli\settings.json（Windows）、/Library/Application Support/GeminiCli/settings.json（macOS） 設定ファイルの中で最強。場所は GEMINI_CLI_SYSTEM_SETTINGS_PATH で変えられる
6 環境変数 .env から読まれるものも含む
7（強い） コマンドラインの旗 起動時 一番強い

つまり、ふつうの値（承認モードの既定など）は、プロジェクトの設定がユーザーの設定に勝ち、システムの設定が両方に勝ち、旗が全部に勝ちます。プロジェクトの .gemini フォルダには、カスタムのサンドボックスの設定ファイルなども置ける、と書かれています。

配列とオブジェクトの合わさり方。 Enterpriseのページには、includeDirectories のような配列は、優先順に連結され、mcpServers のようなオブジェクトは、混ぜ合わされ、名前がぶつかると、優先度が高い定義が勝つ、と書かれています。設定リファレンスには、この合わせ方の説明は、見つかりませんでした。

.env の読み込み順。 設定リファレンスでは、①今のフォルダの .env、②なければ、上の階層へ向けて、.env が見つかるか、プロジェクトのルート（.git のあるフォルダ）か、ホームに着くまで探す、③それでもなければ ~/.env、の順です。DEBUG と DEBUG_MODE は、プロジェクトの .env から、既定で除外されます（.gemini/.env は除外されません）。

設定の画面。 /settings で、設定を開いて編集できます。プロジェクトの設定がユーザーの設定を上書きする、と書かれています。ただし、advanced.autoConfigureMemory は、ユーザーのグローバルな設定だけが読まれます。

例：安全寄りに固めた設定（僕らの組み合わせです）

公式の設定リファレンスには、そのまま写せる完全な例がありませんでした。次は、公式の表にある項目と値を、僕らが組み合わせた例です。動作確認はしていません。

{
  "general": {
    "defaultApprovalMode": "default"
  },
  "security": {
    "folderTrust": { "enabled": true },
    "disableYoloMode": true,
    "enablePermanentToolApproval": false,
    "environmentVariableRedaction": {
      "enabled": true
    }
  },
  "tools": {
    "sandbox": "docker",
    "sandboxNetworkAccess": false
  }
}

environmentVariableRedaction（秘密を含みそうな環境変数を隠す設定。既定は false）は、公式のページに「ベストエフォート（できる範囲で）」と書かれています。このページには、同じ設定の鍵の名前が、別の節では security.allowedEnvironmentVariables などと書かれている、食い違いもありました。使うときは、自分の版のドキュメントで確かめてください。

Plan Mode：読むだけで考えさせる

公式のPlan Modeのページによると、入り方は、起動時の gemini --approval-mode=plan、実行中の Shift+Tab か /plan <目標> です。許可されるのは、読み取り、検索、調査用のサブエージェント、読み取り専用のMCPツールなどで、書けるのは、計画用のディレクトリの .md ファイルだけです。計画の保存先は既定で ~/.gemini/tmp/<project>/<session-id>/plans/ で、general.plan.directory で変えられますが、そこはプロジェクトのルートの中で、書き込みを許すポリシーが要ります。承認では「Yes, automatically accept edits」か「Yes, manually accept edits」を選びます。ページに実験的とは書かれておらず、既定で有効と書かれています。

組織で固める：Enterpriseのページ

公式の「Enterprise」のページは、システムの設定ファイル（上の表の5番目）で、利用者が変えられない設定を配る方法を説明しています。要点は、①"tools": {"sandbox": "docker"} で、ツールの実行をDockerの囲いに入れる、②"tools": {"core": [...]} の許可リストを勧める（ブロックリストの exclude は、既知の悪いものに頼るので弱く、文字列だけのブロックは、回避されうる、と警告）、③"security": {"disableYoloMode": true} を、強く勧める、④MCPは、承認済みのサーバーの定義を、システム側に全部書き、さらに mcp.allowed に名前を並べる。mcp.allowed を省くと、利用者が自分のサーバーを足せてしまう、⑤security.auth.enforcedType でログイン方法を固定、⑥テレメトリでは logPrompts を false にする、です。

公式は、この仕組みについて、うっかりした誤用を防ぎ、会社の方針を強制するためのもので、完全なセキュリティの境界ではない、十分なローカル権限があれば回避できる場合がある、悪意のある管理者権限の人は防げない、と書いています。

最初の10分でやること

公式に書かれている範囲の手順です。順番と選び方は、僕らの整理です。

  1. 自分の承認モードを確かめる。起動して、/settings を開き、「Default Approval Mode」が default になっているか見る（Plan Modeのページに、この項目名がある）。
  2. 信頼するフォルダを有効にする。ユーザーの ~/.gemini/settings.json に、上の security.folderTrust.enabled: true を書き、再起動する。知らないリポジトリを開いたら、ダイアログの一覧（コマンド、MCPサーバー、フック、スキル、設定の上書き）を読んでから、答える。
  3. 新しいプロジェクトや、信頼しきれないコードでは、まず gemini --sandbox（-s）で起動する。DockerかPodmanが動いているか、macOSなら Seatbelt が使えるか確かめる。効いているかの確かめ方として、囲いの外のパスへ書き込ませてみて、「Operation not permitted」が出るかを見る手があります（公式にこの手順が書かれているわけではなく、僕らの提案です。起動時の表示については、読んだ範囲では見つかりませんでした）。
  4. 変更が大きい作業は、/plan <目標> で計画を書かせて、承認の画面で、「manually accept edits」を選ぶ。
  5. 止めたいことは、~/.gemini/policies/ にTOMLで書く（deny）。書いたら /policies list で、モード別の一覧に出るか見る。
  6. YOLOは、囲い（サンドボックス）の中の、使い捨ての作業に限る。個人の設定には、security.disableYoloMode: true を入れておく手もある（これは僕らの見立てで、公式が個人にそうせよと書いているわけではありません）。

自動化（-p）の場面で、読めたこと、読めなかったこと

公式のヘッドレス（-p や、非対話）のページは、出力形式（JSONと、改行区切りのJSONのストリーム。--output-format の選択肢が text、json、stream-json であることは、CLI参照に書かれています）と、終了コード（0 成功、1 一般のエラーやAPIの失敗、42 入力のエラー、53 ターン数の上限）を書いていますが、ツールの承認の扱いは書いていませんでした。自動化の手引き（Automation）のページにも、承認の説明は見つかりませんでした。ポリシーのページから分かるのは、ask_user は、対話でない実行では deny として扱われること、書き込み系のツール（write_file、run_shell_command）の既定が ask_user であることです。この2つを合わせると、-p で、承認モードもポリシーも変えないまま、ファイルの書き換えやシェルの実行を頼むと、拒否されるのではないか、と読めます。ただし、これは僕らの推測で、公式ページに書かれていることではありません。実際の動きは、手元の版で、安全な場所で確かめてください。確かめるまでは、--approval-mode=yolo を、とりあえず付ける、のはやめて、ポリシーで、通したいコマンドの前方一致だけを allow にする（interactive = false の条件も使える）やり方のほうが、公式の仕組みに沿っています（これも僕らの見立てです。書き方の例は、上の「シェルコマンドのルール」にあります）。

気をつけること

出典