Codex の --full-auto は何をするのか:承認とサンドボックスの中身

Codex 公開: 更新:

Codex CLI の --full-auto オプションが内部で設定する承認ポリシーとサンドボックスの組み合わせを解説します。何が自動で何が制限されるか、ワークスペース外やネットワークの扱い、config.toml で同じ設定を固定する方法、使うべき場面と避けるべき場面を整理します。

検証日 2026年10月4日 仕様変更が早い分野です。最新の公式ドキュメントも併せてご確認ください。 記事の作り方と検証手順
目次
  1. 内部で設定される内容
  2. 何が自動で、何が制限されるか
  3. config.toml で固定する
  4. 使うべき場面・避けるべき場面
  5. 対話中に切り替える
  6. まとめ

codex --full-auto は「全部自動でやる」という名前に見えますが、実際にはワークスペースの中だけ自由にしてよいという設定です。ワークスペースの外に書き込んだり、ネットワークに出たりすることは、サンドボックスによって引き続き制限されます。

もう 1 点先に押さえておきます。公式ドキュメントは現在 --full-auto を非推奨としており、代わりに codex exec --sandbox workspace-write を案内しています。フラグ自体は動作するため、何に相当するかを知っておくと置き換えられます。

KEY POINT

この記事で分かること

  • --full-auto が設定する承認ポリシーとサンドボックスの組み合わせ
  • 自動で通るもの、制限されるもの
  • config.toml で同じ設定を固定する方法と、使うべき場面

内部で設定される内容

--full-auto は、次の 2 つをまとめて指定する省略形です。

設定値意味
サンドボックスworkspace-writeカレントディレクトリ配下と一時領域だけ書き込み可。ネットワークは既定で不可
承認ポリシーon-request既定値。サンドボックスの外に出る操作とネットワークアクセスで確認する

承認ポリシーに指定できる値は、2026 年 10 月 4 日時点の設定リファレンスでは on-request、never、そして granular オブジェクトの 3 つです。ドキュメントには「untrusted はサポートされず、on-failure は非推奨。対話的な実行には on-request、非対話的な実行には never を使うこと」と書かれています。

granular は、確認の種類ごとに「出す / 自動で拒否する」を決める書き方です。

[approval_policy.granular]
sandbox_approval = true      # サンドボックスのエスカレーション確認を出す
rules = true                 # execpolicy の prompt ルールによる確認を出す
mcp_elicitations = true      # MCP の elicitation を自動拒否せず出す
request_permissions = true   # request_permissions ツールからの確認を出す
skill_approval = true        # スキルスクリプトの承認確認を出す

false にした種類は確認が出ず、自動的に拒否されます。

用語解説

サンドボックスと承認の違い: 承認は「実行前にユーザーに聞くか」、サンドボックスは「OS レベルで何ができるか」です。--full-auto は聞く回数を減らしますが、できることの範囲はサンドボックスが決めています。詳しくは親記事の approval mode と sandbox 設定の違い を参照してください。

何が自動で、何が制限されるか

操作--full-auto での扱い
ワークスペース内のファイル読み書き自動
ワークスペース内でのコマンド実行(テスト、ビルド)自動
ワークスペース外への書き込み(~/.ssh など)サンドボックスが拒否
ネットワーク(npm install、curl)既定で拒否。失敗時に「サンドボックス外で再実行してよいか」を確認
Git のコミット自動(ワークスペース内)
git pushネットワークが必要なため、既定では失敗して確認が入る

「npm install が失敗した」という場面では、確認に答えて許可すればサンドボックス外で再実行されます。毎回聞かれるのが煩わしければ、config.toml でネットワークだけ許可します。

config.toml で固定する

approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

これで --full-auto を付けなくても同じ挙動になり、ネットワークも許可されます。ネットワークを許可すると外部へのデータ送信も可能になるため、信頼できるリポジトリでだけ使ってください。

使うべき場面・避けるべき場面

場面判断
テストが整備されたリポジトリでのリファクタリング向いている。テストが通るまで自律的に進められる
lint エラーの一括修正向いている
初めて触るコードベースの調査--sandbox read-only の方が安全
本番の認証情報がある環境避ける。サンドボックスは読み取りを制限しない
CI での完全自動実行-a never との組み合わせを検討。使い捨て環境が前提

読み取りは制限されない

workspace-write は書き込みを制限しますが、ワークスペース内のファイル読み取りは自由です。.env などの秘密情報はワークスペースの外に置いてください(秘密情報を読ませないための設定)。

対話中に切り替える

セッション中に /approvals を実行すると、承認モードを切り替えられます。調査だけで始めて途中から実装に移るときに使います。

まとめ

  • --full-auto は approval_policy = "on-request" と sandbox_mode = "workspace-write" の省略形。公式は非推奨とし codex exec --sandbox workspace-write を案内している
  • ネットワークが必要な操作は失敗して確認が入る。network_access = true で許可できる
  • サンドボックスは読み取りを制限しないため、秘密情報はワークスペース外に置く
  • 調査は read-only、テストが整ったリポジトリのリファクタリングは --full-auto が向いている

よくある質問

--full-auto は全部自動という意味ですか?
違います。ワークスペース内の読み書きを自動にする設定で、ワークスペース外への書き込みやネットワークはサンドボックスで制限されたままです。
--full-auto は今も推奨されるフラグですか?
いいえ。公式ドキュメントは非推奨としており、代わりに codex exec --sandbox workspace-write を案内しています。フラグ自体は動作し、approval_policy = on-request と sandbox_mode = workspace-write に相当します。
Codex の auto(自動)モードはどれですか?
Codex に auto という名前のモードはありません。承認ポリシーの値は on-request と never、それに granular オブジェクトの 3 つです。自動で進めたい場合は codex exec --sandbox workspace-write を使います。
--full-auto と --dangerously-bypass-approvals-and-sandbox の違いは?
後者はサンドボックスも承認も完全に無効にします。--full-auto はサンドボックスが有効なままなので、壊せる範囲が限定されます。

参考にした一次情報

この記事は公式ドキュメントを基に AI が下書きを作成し、運営者が内容を確認して公開しています。誤りを見つけた場合は お問い合わせからお知らせください。