はじめに

Claude Code を使い始めて最初に感じる違和感は、おそらく「承認プロンプトの多さ」です。ファイルを1つ直すたびに聞かれ、テストを1回走らせるたびに聞かれ、気づけば Enter を連打している。一方で、承認を全部スキップしてしまうと、今度は rm のような取り返しのつかないコマンドが黙って実行される不安がつきまといます。

この「手間」と「事故」のバランスを取るためのダイヤルが、Claude Code の許可モード（permission mode）です。2026年9月時点では6種類あり、どれを選ぶかで「実行前に誰が確認するのか」が変わります。

この記事では、次の3点を扱います。

Claude Code の6モードを「誰が承認するか」という1本の軸で整理し、切り替え方と起動時の決まり方を押さえる
実務で効果が大きい Plan モードから作業を始める手順を、具体的な依頼例で追う
同じ課題を OpenAI の Codex がどう解いているか（サンドボックス × 承認ポリシー × レビュアー）を調べ、対応表にまとめる

想定読者は、Claude Code を触り始めたエンジニア、そしてチーム導入で「どこまで自動化して大丈夫か」を決める立場の方です。記述は公式ドキュメント（Claude Code は code.claude.com、Codex は learn.chatgpt.com）の執筆時点の内容にもとづいています。バージョンによって画面の文言や既定値が変わる領域なので、最終的には手元の claude --help と公式ページで確認してください。

まず全体像を1枚で見ておきましょう。6つのモードは「制限の強さ」の順に並んでいるというより、「承認という仕事を誰が引き受けるか」が違います。

図1: 6つのモードを「承認者」で整理したもの。

前提知識: 「聞くかどうか」と「どこまで届くか」は別のレイヤー

モードの話に入る前に、混同しやすい2つの概念を分けておきます。

許可モードは、Claude が何かを実行しようとした「前」に、確認を取るかどうか、取るなら誰に取るかを決める仕組みです。対してサンドボックスやコンテナによる隔離は、実行された「時」に、そのコマンドがどこまで届くか（書き込める範囲、ネットワーク、ホスト OS への到達可否）を決める仕組みです。

図2: モードは承認の手間を減らし、サンドボックスは事故の範囲を狭める。役割が違うので両方を設計する

公式ドキュメントも、許可モードは「Claude が実行前に聞くかどうか」を決め、Bash サンドボックスや外側の隔離境界は「実行された操作が何に届くか」を決める、と明確に分けて説明しています。この区別を頭に置いておくと、後半の Codex との比較がすっきり読めます。Codex は最初から「サンドボックス」と「承認」を独立した設定として設計しているからです。

Claude Code の6つのモード一覧

何が承認なしで動くか

まず公式の一覧を、私なりの言葉で表にまとめます。設定値（--permission-mode やステータスバーで使う名前）も併記します。

モード	設定値	承認なしで動くもの	向いている場面
Manual	`default`（`manual` も可）	読み取りのみ	初めての環境、慎重に進めたい作業
Accept Edits	`acceptEdits`	読み取り、ファイル編集、`mkdir` `mv` `cp` など基本的なファイル操作	自分でレビューしながらコードを回す
Plan	`plan`	読み取りと調査（Auto が使える環境では分類器が承認した調査コマンドも）	変更前にコードベースを探索する
Auto	`auto`	安全性チェックを通ったすべての操作	長いタスク、承認疲れの解消
Don't Ask	`dontAsk`	読み取りと事前許可済みツール。確認が必要な操作は拒否	CI やスクリプト実行
Bypass Permissions	`bypassPermissions`	すべて	隔離されたコンテナや VM の中だけ

ここで注意したいのは、Plan と Don't Ask は「制限の緩さ」の順番に収まらないことです。Plan は「編集を止めて調査させる」モードで、Don't Ask は「聞く代わりに拒否する」モード。どちらも人が承認するかどうかではなく、承認プロンプトそのものを別の仕組みに置き換えています。だから図1のように「承認者」で見ると、それぞれの立ち位置がはっきりします。

起動時のモードはどう決まるか

2026年9月時点で見落としやすいのが、Pro / Max / Team プランではセッション開始時の既定モードが Auto になっている点です（macOS / Linux / WSL は v2.1.228 以降、Windows ネイティブは v2.1.233 以降）。Enterprise プランや Console の API キー、claude -p の非対話実行、Bedrock などのクラウドプロバイダ経由では Manual が既定です。

起動時のモードは次の優先順で決まります。

--permission-mode フラグ、または --dangerously-skip-permissions
設定ファイルの permissions.defaultMode
プランやプロバイダに応じた組み込みの既定値

2番目には落とし穴があります。プロジェクト側の .claude/settings.json や .claude/settings.local.json に "auto" や "bypassPermissions" を書いても無視されます。リポジトリにチェックインした設定で他人の環境を勝手に無人化できないようにするための仕様です。Auto を既定にしたければ ~/.claude/settings.json に書く必要があります。

// ~/.claude/settings.json — このマシンのターミナルセッションを常に Manual で始める
{
  "permissions": {
    "defaultMode": "default"
  }
}

Auto を止めたい組織は、管理者設定で permissions.disableAutoMode を "disable" にすると Shift+Tab のサイクルから Auto が消えます。

切り替え方: Shift+Tab のサイクル

作業中の切り替えは CLI なら Shift+Tab です。順番には少し癖があります。

図3: Auto から始まった場合、最初の Shift+Tab で Manual に移り、以降は Manual → Accept Edits → Plan → (Bypass) → (Auto) → Manual と回る。

補足すると次のとおりです。

Auto は利用可能な環境でだけサイクルに現れ、確認なしで切り替わります
Bypass は --permission-mode bypassPermissions、--dangerously-skip-permissions、または --allow-dangerously-skip-permissions を付けて起動した場合だけサイクルに入ります。3つ目のフラグは「サイクルに追加するが有効化はしない」ので、--permission-mode plan と組み合わせて「Plan で始めて、承認後に Bypass へ」という使い方ができます
Don't Ask はサイクルに一切出てきません。--permission-mode dontAsk で起動時に指定します
Manual または Accept Edits で Bash の承認プロンプトが出たとき、Auto が使える環境なら「Yes, and switch to auto mode」という選択肢が追加されます（v2.1.247 以降）。承認と同時に Auto へ移れます

VS Code 拡張ではプロンプト欄下部のモード表示をクリックして切り替えます。ラベルは Manual / Edit automatically / Plan / Auto / Bypass permissions で、Bypass は拡張の設定で「Allow dangerously skip permissions」を有効にしないと出てきません。デスクトップアプリの Code タブでは送信ボタン横のセレクタ、Web とモバイル（claude.ai/code）ではプロンプト欄横のドロップダウンです。クラウドセッションでは Bypass は選べません。

どのモードでも自動承認されない操作

「Bypass なら何でも通る」と思われがちですが、公式にはどのモードでも自動承認されない操作が列挙されています。代表的なものを挙げます。

明示的な ask ルールに一致するツール
ユーザーとの対話が必要なツール（AskUserQuestion や、requiresUserInteraction の印が付いた MCP ツール）
rm -rf / や rm -rf ~ のような、クリティカルパスを対象にした rm / rmdir。allow ルールや PreToolUse フックで許可しても通りません

また .git、.claude、.vscode、.husky などの保護パスへの書き込みは、Bypass 以外では自動承認されず、Manual と Accept Edits では確認、Auto では分類器へ回され、Don't Ask では拒否されます。deny ルールは Bypass を含むすべてのモードで効きます。この「最後の砦」があるので、モードを緩める前に deny ルールを書いておく、という順番が実務では大切になります。

各モードの実務的な使いどころ

Manual: 読み取り専用コマンドは止まらない

Manual はすべてを確認するモードですが、「すべて」の中に読み取り専用の操作は含まれません。ファイルの読み取り、検索、そして ls のような組み込みの読み取り専用 Bash コマンドは確認なしで実行されます。「ファイル一覧を見るだけでいちいち止まる」ことはないので、最初は Manual で始めても思ったほど煩わしくありません。

Manual という表示名は v2.1.200 以降のもので、設定値としては default が正式、manual は別名として受け付けられます。フックや SDK からは default を使います。

Accept Edits: 編集は流し、コマンドだけ見る

Accept Edits は作業ディレクトリ内のファイル作成・編集を確認なしで通します。加えて mkdir、touch、rm、rmdir、mv、cp、sed といった基本的なファイル操作コマンドも自動承認されます（LANG=C などの安全な環境変数や timeout、nice などのラッパー付きでも同様）。

ポイントは「作業ディレクトリ（と additionalDirectories）の中に限る」ことです。外のパス、保護パス、クリティカルパスへの rm、そして読み取り専用セット以外の一般的な Bash コマンドは相変わらず確認が入ります。「編集は後で git diff を見ればいい、コマンドだけは目で追いたい」という人に向くモードです。

# Accept Edits で起動する
claude --permission-mode acceptEdits

Plan: 調べて、書いて、承認を待つ

Plan モードは Claude に「変更を提案するが実行はしない」よう指示するモードです。ファイル読み取り、検索、調査用のシェルコマンド実行はできますが、ソースの編集はプランを承認するまでブロックされます。詳しい手順は次の章で追います。

一点だけ補足すると、Auto が使える環境では useAutoModeDuringPlan（既定で有効）により、調査中のシェルコマンドは人ではなく分類器が審査します。承認されたコマンドは実行され、却下されたものはブロックされます。Auto が使えない環境では、読み取り専用セット以外のコマンドは従来どおり確認が入ります。

Auto: 承認という仕事を別のモデルに委ねる

Auto は「分類器（classifier）」と呼ばれる別のモデルが、実行前の操作を審査するモードです。依頼の範囲を超える操作、認識していないインフラを対象にする操作、Claude が読んだ悪意あるコンテンツに誘導されたように見える操作をブロックします。

審査の順番を図にすると次のようになります。

図5: Auto は無条件に通すモードではなく、承認を分類器に委ねるモード。

公式の「既定でブロックされる操作」から、実務で遭遇しやすいものを抜粋します。

curl | bash のようなダウンロードして即実行
機密データの外部送信、本番デプロイやマイグレーション、クラウドストレージの一括削除
IAM やリポジトリ権限の付与、共有インフラの変更
セッション開始前から存在したファイルの不可逆な破壊、force push
git reset --hard、git checkout -- .、git clean -fd、git stash drop など未コミットの変更を捨てる操作
terraform destroy などリソースを破壊する IaC 操作
セキュリティ関連のテストやアサーションをコメントアウト・削除する変更（v2.1.200 以降）

一方で、作業ディレクトリ内のファイル操作、ロックファイルに宣言済みの依存関係のインストール、読み取り専用の HTTP リクエスト、作業中リポジトリへの push などは既定で許可されます。

運用上、押さえておきたい仕様が4つあります。

会話で宣言した境界は分類器が守る。 「push はしないで」「デプロイ前に私が確認する」と伝えると、既定で許可される操作でも分類器がブロックします。ただしこれはトランスクリプトから毎回読み直されるので、コンテキスト圧縮で消えると失われます。確実に守らせたいなら deny ルールにします
ブロックが続くと Auto は一時停止する。 連続3回、または累計20回ブロックされると人に確認するプロンプトに戻り、承認すると Auto が再開します。この閾値は変更できません。頻発するなら分類器にインフラの情報が足りない合図なので、/feedback で報告するか管理者に autoMode.environment で信頼するリポジトリやサービスを登録してもらいます
広い allow ルールは Auto に入ると落とされる。 Bash(*) や Bash(python*)、パッケージマネージャの run 系など、任意コード実行を許すルールは Auto 中は無効化され、Bash(npm test) のような狭いルールだけが残ります
分類器はツールの実行結果を見ない。 見るのはユーザーの発言、ツール呼び出し、CLAUDE.md の内容で、ファイルや Web ページの中身に仕込まれた指示で分類器を直接操られない設計です

利用条件にも注意が必要です。Anthropic API では Claude Opus 4.6 以降、Sonnet 4.6 以降、または Fable 系モデルが必要で、Bedrock や Foundry などでは Sonnet 5、Opus 4.7 以降、Fable 系に限られます。Enterprise プランや API 利用では分類器の呼び出しもトークン使用量に計上されるため、コストとレイテンシの観点でも「読み取りと作業ディレクトリ内の編集は分類器を通らない」という仕様は覚えておく価値があります。

Don't Ask: 聞く代わりに拒否する

Don't Ask は「確認プロンプトが出るはずの操作をすべて自動で拒否する」モードです。読み取り、読み取り専用 Bash、permissions.allow に一致する操作、PreToolUse フックが許可した操作だけが動きます。人が待っていない CI パイプラインで、「想定外のツール呼び出しは大きな音を立てて失敗してほしい」ときに向いています。

# CI でテストだけ実行させる。npm test と Read 以外は拒否される
claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

明示的な ask ルールに一致する操作も、AskUserQuestion も拒否されます。「聞かれたら困る場面」に置くモードであって、Bypass の代替ではありません。

Bypass Permissions: 隔離環境の外では使わない

--dangerously-skip-permissions と同じものです。プロンプトも安全性チェックも無効になり、保護パスへの書き込みも即実行されます。公式は「ホストに損害を与えられない、インターネットに出られないコンテナや VM、devcontainer の中だけで使う」と明記しています。

# Bypass Permissions で起動（隔離環境の中でだけ）
claude --dangerously-skip-permissions

安全弁も用意されています。

セッション途中からは入れません。起動時にフラグか permissions.defaultMode で有効化しておく必要があります
Linux / macOS では root や sudo 配下では起動を拒否します（認識済みサンドボックス内は例外）
初回の対話セッションでは責任を受け入れる警告ダイアログが出ます。断ると終了します
管理者は permissions.disableBypassPermissionsMode を "disable" にして組織全体で封じられます
Claude Code on the web はチェックインされた設定の bypassPermissions と dontAsk を無視します

公式ドキュメントは「プロンプトを減らしたいなら Bypass ではなく Auto を使え」と繰り返しています。Bypass はプロンプトインジェクションや意図しない操作に対する防御がゼロになるからです。

実践: Plan モードから作業を始める

ここからが本題です。書籍やベストプラクティスで繰り返し推奨されているのが「実務の新しいタスクは Plan から始める」という進め方です。理由は単純で、いきなり実装に入るより、何をどう作るかを先に擦り合わせたほうが手戻りが少ないからです。特に、初めて触るコードベース、複数ファイルにまたがる機能追加、大規模なリファクタリングほど効果が出ます。

図4: 承認するまでコードは1行も変わらない。

手順

例として、既存の Express 製 API に「DB 接続まで確認するヘルスチェックエンドポイント」を追加するタスクを想定します。以下の手順は公式ドキュメントの仕様にもとづくもので、選択肢の文言は執筆時点のものです。

プロジェクトのディレクトリで Claude Code を起動し、Shift+Tab で「plan mode on」の表示になるまで切り替えます。1回きりなら依頼文の先頭に /plan を付ける方法でも構いません。最初から Plan で起動するなら claude --permission-mode plan です

次のような依頼を入力します

/api/healthz を追加してください。200 を返す条件は、アプリが起動していることと、
既存の DB コネクションプールで SELECT 1 が成功することです。失敗時は 503 と
失敗理由を JSON で返してください。既存のロギングとエラーハンドリングの流儀に合わせてください。

Claude がルーティングの構成、DB クライアントの初期化箇所、既存のエラーハンドラを Read / Grep / Glob で調べます。この間、編集は行われません
情報が足りないと判断すると AskUserQuestion ツールで構造化された質問が出ます。たとえば「タイムアウトは既存の DB クエリと同じ値でよいか」「認証ミドルウェアの外に置くか」といった質問に答えると、プランの精度が上がります
プランが提示されます。既定では ~/.claude/plans/ 配下に Markdown として保存されます。Ctrl+G を押すとエディタで開いて直接書き換えられます
承認画面で3つから選びます
- Yes, and use auto mode: 承認して Auto で実装を始める（Auto が使えない環境では Yes, auto-accept edits になり Accept Edits へ移行。Bypass を有効化して起動していれば Bypass へ移行する選択肢に変わる）
- Yes, manually approve edits: 承認したうえで、編集を1件ずつ確認する
- No, keep planning: Plan に留まり、直してほしい点を伝える
承認すると編集可能なモードに移り、実装が始まります。終わったらテストを流し、期待どおり 200 と 503 が返るか確認します。もう一度計画したくなったら Shift+Tab で Plan に戻るか、次の依頼に /plan を付けます

承認せずに Plan を抜けたいときは Shift+Tab を押すだけです。showClearContextOnPlanAccept を有効にしていると、承認時に「計画中のコンテキストを消してから実装に入る」選択肢が先頭に加わります。調査で膨らんだコンテキストを一度リセットしてから実装させたいときに便利です。

プランの保存先をプロジェクト内にする

プランは既定でユーザーのホーム配下に保存されますが、settings.json の plansDirectory で変更できます。プロジェクト内に置けばリポジトリにコミットしてチームで共有できます。

// .claude/settings.json — プランをプロジェクト内に保存する
{
  "plansDirectory": "./docs/plans"
}

この設定はプロジェクト単位・ユーザー単位のどちらにも書けますが、過去に「プロジェクト側の設定が効かない」という報告も上がっている領域です。設定後、最初のプランがどこに保存されたかは一度確認しておくと安心です。

Plan を挟まないほうが速い場面

Plan モードには向き不向きがあります。誤字の修正や、1ファイルで完結する小さな変更では、Plan を挟まずに Manual や Accept Edits で直接依頼したほうが早く終わります。目安は「変更内容を一文で言えるかどうか」です。一文で言えるなら Plan は不要、言えないなら Plan から始める、と覚えておくと判断に迷いません。

プロジェクトの既定を Plan にする

チームで「新しいタスクは必ず Plan から」を徹底したいなら、プロジェクトの設定で既定モードを Plan にできます。auto や bypassPermissions と違い、plan はプロジェクト側の .claude/settings.json からでも有効です。

// .claude/settings.json — このプロジェクトのターミナルセッションを Plan で始める
{
  "permissions": {
    "defaultMode": "plan"
  }
}

VS Code 拡張はプロジェクト側の設定を起動モードの決定に使わないので、そちらでは VS Code のユーザー設定 claudeCode.initialPermissionMode を plan にします。

Codex の場合: サンドボックス × 承認ポリシー × レビュアー

ここからは OpenAI の Codex（CLI、IDE 拡張、ChatGPT デスクトップアプリ）が同じ課題をどう扱っているかを見ていきます。設計思想の違いがそのまま設定項目の違いに表れていて、Claude Code のモードを理解した後に読むと対比がはっきりします。

3つの軸で権限が決まる

Codex は「モード」を1つの値として持つのではなく、次の3つを組み合わせます。

図6: 画面のプリセットは、この3軸の組み合わせに名前を付けたもの。

サンドボックス（sandbox_mode）: read-only（読むだけ）、workspace-write（ワークスペース内と一時ディレクトリだけ書ける）、danger-full-access（制限なし）。ワークスペース内で完結する操作はここで自動的に許可されます
承認ポリシー（approval_policy）: on-request（サンドボックスの境界を越えるときに聞く）と never（聞かない）。以前あった untrusted は廃止されました
レビュアー（approvals_reviewer）: user（人が承認）と auto_review（レビュアーエージェントが承認）

デスクトップアプリや IDE 拡張の画面に出るプリセットは、この組み合わせに名前を付けたものです。

プリセット	サンドボックス	承認ポリシー	レビュアー	位置づけ
Ask for approval	`workspace-write`	`on-request`	`user`	公式が「まずはここから」と推奨する出発点
Approve for me（設定名は Auto-review）	`workspace-write`	`on-request`	`auto_review`	境界を越える要求だけを自動審査
Full access	`danger-full-access`	`never`	なし	隔離環境以外では非推奨
Custom	`config.toml` で指定	同左	同左	名前付きプロファイルなど

デスクトップアプリでは Ask for approval だけが最初から使え、Approve for me と Full access は Settings > General の Permissions で有効化してからメニューに出ます。CLI では /permissions コマンドで切り替えます。

CLI のフラグと config.toml の対応も押さえておきます。

# 明示的に指定する
codex --sandbox workspace-write --ask-for-approval on-request   # Ask for approval 相当
codex --sandbox read-only --ask-for-approval on-request         # 調査だけさせる
codex --ask-for-approval never                                  # 承認プロンプトを出さない（-a never）
codex --full-auto                                               # workspace-write + 承認なしのプリセット
codex --dangerously-bypass-approvals-and-sandbox                # Full access 相当（--yolo）

# ~/.codex/config.toml — 既定値の例
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"          # 自動審査にするなら "auto_review"

# workspace-write ではネットワークが既定で無効。必要なら明示的に許可する
[sandbox_workspace_write]
network_access = true

ネットワークが既定で無効という点は Claude Code との大きな違いです。npm install や外部 API 呼び出しが止まったときは、まずこの設定を疑うことになります。

Plan モードとサンドボックスの関係

Codex にも Plan モードがあり、/plan または Shift+Tab で入ります（執筆時点の 0.14x 系 CLI では Shift+Tab で Default と Plan を行き来する形です。以前は Plan / Pair / Execute の3モードを巡回する実験的な collaboration mode として提供されていた時期もあり、名称と切り替え方はバージョンで変化しています）。

ここで Claude Code との設計差が出ます。Claude Code の Plan モードは「承認するまで編集をブロックする」ことを許可システム側で強制します。一方 Codex の Plan モードは「調査して計画を提案する」という振る舞いの指示が中心で、ファイルを書けないことをシステムとして強制したいなら、/permissions で read-only サンドボックスを別途選びます。公式ドキュメントも「変更せずに相談や計画をしたいなら /permissions で read-only に切り替える」と案内しています。

つまり Codex では「振る舞い（Plan）」と「境界（read-only）」を別々に指定する、と覚えておくと迷いません。

Auto-review: 境界を越える操作だけをレビュアーが審査する

Claude Code の Auto モードに相当するのが Codex の Auto-review（画面上は Approve for me）です。仕組みを図にします。

図7: Auto-review はレビュアーの交代であって権限の追加ではない。

要点は次のとおりです。

レビューが発生するのは、サンドボックス境界を越える要求だけです。権限昇格を伴うシェル実行、ブロックされたネットワークアクセス、書き込み可能ルートの外への編集、承認が必要な MCP やアプリのツール呼び出し、Computer Use での新しいドメインへのアクセスなどが対象で、境界内の通常操作はレビューを通りません
レビュアーは別の Codex エージェントで、要約された会話と当該の承認要求だけを見て判断します。メインエージェントの隠れた推論は渡されません
既定ポリシーでブロックされるのは、機密情報や認証情報の外部送信、認証情報やトークンの探索、広範または永続的なセキュリティ低下、不可逆な破壊的操作といった類型です。ポリシー本文は OSS の Codex リポジトリに公開されており、ユーザーは [auto_review].policy、企業は guardian_policy_config で差し替えられます
拒否されたメインエージェントには「同じ結果を回り道や迂回で狙わない。より安全な代替に切り替えるか、ユーザーに聞く」という強い指示が付きます
安全弁として、1ターン内で3連続の拒否、または直近50件のレビュー中10回の拒否でターンが中断されます。承認以外の結果が出れば連続カウントはリセットされます
どうしても通したい1件は /approve で「Auto-review Denials」の一覧から選んで1回だけ再試行できます。その再試行もレビューを通ります

approval_policy = "never" や danger-full-access、--yolo を使うと境界を越える承認要求そのものが発生しないため、Auto-review は機能しません。Claude Code の「Auto を使うなら Bypass は使うな」と同じ構図です。

公式が挙げる「レビュー回数を減らす正攻法」も実務的です。レビューが頻発するならレビュアーに許可を学習させるのではなく、writable_roots に意図して使う隣接ディレクトリを追加する、["pnpm", "run", "lint"] のように狭いコマンドプレフィックスのルールを足す、といった「境界側の調整」を先にやる、という考え方です。

権限プロファイル（ベータ）

2026年9月時点で、Codex は sandbox_mode を置き換える権限プロファイルをベータ提供しています。:read-only、:workspace、:danger-full-access の組み込みプロファイルに加えて、ファイルシステムとネットワークのルールを1つの名前でまとめられます。

# ~/.codex/config.toml — ワークスペースは書けるが .env は読ませず、api.openai.com だけ通す例
default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

注意点として、プロファイルと旧来の sandbox_mode 系設定は併用できません。どちらかを使い、sandbox_mode が設定ファイルやフラグに残っていると旧来の設定が優先されます。また network.enabled = true にしてもプロキシ（features.network_proxy）を有効にしないとドメインルールは強制されません。Claude Code に「設定ファイルからの auto が効かないケース」があるのと同様、Codex にも「効いているつもりで効いていない」典型パターンがあるので、初回は挙動を確認する運用をおすすめします。

サンドボックスの実装は OS ごとに異なります。macOS は Seatbelt、Linux / WSL は bubblewrap と seccomp（互換パスとして Landlock）、Windows ネイティブは専用のサンドボックスユーザーとファイアウォールを使う elevated サンドボックスが最も強力です。Linux では sudo apt install bubblewrap が前提になります。

Claude Code と Codex の対応表

両者を並べて整理します。名前が似ていても中身が違うところを太字にしています。

観点	Claude Code	Codex
権限の表現	1つの許可モード（6種）	サンドボックス × 承認ポリシー × レビュアーの組み合わせ
すべて人が確認	Manual（`default`）	`workspace-write` + `on-request` + `user`（Ask for approval）。ただしワークスペース内の編集と通常コマンドは無審査
編集は自動、コマンドは確認	Accept Edits	該当プリセットなし（Ask for approval が近い）
調査だけ	Plan（編集ブロックを許可システムが強制）	Plan モード（振る舞いの指示）+ `read-only` サンドボックス（境界は別指定）
AI が承認	Auto（分類器が全操作を審査。読み取りと作業内編集は除く）	Approve for me / Auto-review（境界を越える要求だけを審査）
聞かずに拒否	Don't Ask	`approval_policy = "never"` + 狭いサンドボックス（read-only や workspace-write）+ ルール
全部通す	Bypass Permissions（`--dangerously-skip-permissions`）	Full access（`danger-full-access` + `never`、`--yolo`）
途中での切り替え	Shift+Tab / `--permission-mode` / `defaultMode`	`/permissions` / `--sandbox` `--ask-for-approval` / `config.toml`
AI 承認の安全弁	連続3回 or 累計20回のブロックで一時停止	1ターン内で3連続 or 直近50件中10回の拒否でターン中断
拒否の手動上書き	`/permissions` の Recently denied から再試行	`/approve` で1件だけ再試行
ネットワーク	モードでは制限しない（Bash サンドボックスで制御）	`workspace-write` では既定で無効
事前ルール	`permissions.allow` / `ask` / `deny`	command rules（allow / prompt / forbid）と権限プロファイル
管理者による封じ込め	`disableAutoMode`、`disableBypassPermissionsMode`（managed settings）	`allowed_permission_profiles`、`allowed_sandbox_modes`、`guardian_policy_config`（requirements.toml）

設計思想の違いを一言でまとめると、Claude Code は「承認者を切り替えるダイヤル」を前面に出し、サンドボックスは任意の追加防御として置いています。Codex は「サンドボックスの境界」を土台にして、その境界を越えるときの承認者を切り替えます。だから Claude Code では「Auto を使うならサンドボックスも設計する」が注意点になり、Codex では「ネットワークが既定で閉じている」が最初につまずくポイントになります。

実務での運用指針（両ツール共通）

最後に、どちらのツールでも通用する進め方を、判断フローとしてまとめます。

図8: モードは固定ではなく、作業の途中で切り替えてよい。

判断の順番を文章にすると次のとおりです。

危険な操作は先にルールで塞ぐ。 Claude Code なら permissions.deny（全モードで有効）、Codex なら forbid のコマンドルールや .env への deny。モードを緩めるのはその後です
新しいタスクは Plan から。 一文で diff を説明できない変更は、調査とプランに時間を使ったほうが結果的に速く終わります
自動化したいなら「AI 承認」を選び、「全部通す」は選ばない。 Claude Code の Auto、Codex の Auto-review はどちらも、承認をなくすのではなく承認者を替える仕組みです。ブロックが続いたら設定不足の合図として扱い、信頼するインフラや書き込み可能ルートを設定側に足します
無人実行は「拒否がデフォルト」で。 CI では Claude Code の dontAsk + --allowedTools、Codex の -a never + read-only または workspace-write + 狭いルール、という組み合わせで「想定外の操作は失敗する」状態にします
Bypass / Full access はコンテナの中だけ。 ホストの認証情報や他のリポジトリに届かない環境を先に用意し、その中で使います。Claude Code は root で起動できず、初回に責任を受け入れるダイアログが出ます。Codex もフルアクセスを有効化する前に警告を出し、Approve for me を推奨します

チームで導入するなら、管理者側で「使えるモードの上限」を決めておくのが現実的です。Claude Code は managed settings の disableAutoMode と disableBypassPermissionsMode、Codex は requirements.toml の allowed_permission_profiles（または移行期間中の allowed_sandbox_modes）と guardian_policy_config で、開発者側の設定が上書きできない上限を作れます。

トラブルシューティング

よくある「設定したのに効かない」を表にします。

症状	ツール	原因として多いもの	対処
`defaultMode: "auto"` を書いたのに Manual で起動する	Claude Code	プロジェクトの `.claude/settings.json` に書いている	`~/.claude/settings.json` に移す
Shift+Tab を押しても Bypass が出ない	Claude Code	起動時に有効化していない	`--allow-dangerously-skip-permissions` や `--permission-mode bypassPermissions` を付けて起動し直す
Auto が「unavailable」になる	Claude Code	モデルが未対応、`disableAutoMode` が設定されている、サーバー側で一時停止	モデルと設定を確認し、新しいセッションを開始する
Auto で同じ操作が何度もブロックされる	Claude Code	分類器がインフラを信頼していない	`/feedback` で報告、管理者に `autoMode.environment` を設定してもらう。会話で宣言した境界が残っていないかも確認
`npm install` や API 呼び出しがブロックされる	Codex	`workspace-write` でネットワークが既定で無効	`[sandbox_workspace_write] network_access = true`、または権限プロファイルで `network.enabled = true` とプロキシ有効化
権限プロファイルを書いたのに効かない	Codex	`sandbox_mode` が設定ファイルやフラグに残っている	旧設定を削除し、プロファイルに一本化する
Auto-review が一度も動かない	Codex	`approval_policy = "never"` や `danger-full-access` で境界越えの承認要求が発生しない	`on-request` と `workspace-write`（または `read-only`）に戻す
Linux でサンドボックス警告が出る	Codex	`bwrap` が未インストール、または AppArmor の制限	`sudo apt install bubblewrap`、必要なら `bwrap-userns-restrict` プロファイルを読み込む

まとめ

Claude Code の6つの許可モードは「制限の強弱」ではなく「承認という仕事を誰が引き受けるか」で捉えると整理しやすい。人（Manual / Accept Edits / Plan）、分類器（Auto）、ルールのみ（Don't Ask）、なし（Bypass）の4種類
2026年9月時点で Pro / Max / Team は Auto が既定の起動モード。Shift+Tab のサイクルは Manual → Accept Edits → Plan が基本で、Bypass と Auto は条件付きで加わり、Don't Ask はサイクルに出ない
実務の新しいタスクは Plan から始める。承認するまでコードは変わらず、承認時に Auto / 都度確認 / 練り直しを選べる。一文で言える小変更は Plan を挟まない
Codex は「サンドボックス × 承認ポリシー × レビュアー」の組み合わせで権限を決める。Ask for approval が出発点、Approve for me（Auto-review）が Claude Code の Auto に相当し、ネットワークは既定で閉じている
どちらも「全部通す」モードは隔離環境専用。自動化したいなら AI 承認を選び、ブロックが続くなら設定側（信頼インフラ、書き込み可能ルート、ルール）を直す

次のステップとしては、Claude Code なら permissions の allow / ask / deny ルールと Bash サンドボックス（/sandbox）、Codex ならコマンドルールと権限プロファイルを触ってみると、モードだけでは決めきれない「境界の設計」が一段深く理解できます。

参考リソース

Claude Code Docs: Choose a permission mode — https://code.claude.com/docs/en/permission-modes
Claude Code Docs: Permissions — https://code.claude.com/docs/en/permissions
Claude Code Docs: Configure auto mode — https://code.claude.com/docs/en/auto-mode-config
Claude Code Docs: Sandboxing — https://code.claude.com/docs/en/sandboxing
Anthropic Engineering: Claude Code auto mode — https://www.anthropic.com/engineering/claude-code-auto-mode
Codex Docs: Permissions（permission modes） — https://learn.chatgpt.com/codex/permission-modes
Codex Docs: Sandbox — https://learn.chatgpt.com/codex/sandboxing
Codex Docs: Auto-review — https://learn.chatgpt.com/codex/sandboxing/auto-review
Codex Docs: Permission profiles — https://learn.chatgpt.com/codex/permissions
Codex Docs: Agent approvals & security — https://learn.chatgpt.com/codex/agent-approvals-security
Auto-review の既定ポリシー（OSS）— https://github.com/openai/codex/blob/main/codex-rs/core/src/guardian/policy.md