はじめに — 「AIが勝手にコマンドを実行したらどうしよう」に、先に答えておきたい
Codex（コーデックス）を初めて触るとき、いちばん最初に湧いてくる不安って、たぶんこれなんですよね。
「ターミナルでAIにお願いしたら、こっちが見てないうちにファイルを書き換えたり、変なコマンドを流したりしないの…？」
正直に言いましょう。その不安、めちゃくちゃ健全です。むしろ、そこが気になる人ほど、AIに開発を任せる筋がいいと思うんです。だって、どこまで自動でやらせて、どこから人間が確認するか ——それを決めるのが、AIを道具として使いこなす人の仕事だから。
そしてCodexには、その「どこまで任せるか」をちゃんと自分で決めるための仕組みが、最初から用意されています。それが今日の主役、承認モード（approval mode）とサンドボックス（sandbox） です。
この記事では、Codexをまだ触ったことがない人に向けて、この2つだけを、とことんかみ砕いて解説します。あれもこれもは詰め込みません。読み終わるころには、「AIに勝手に動かれるのが怖い」から「自分で任せる範囲を決められる」に変わっているはずです。10分でできる練習も最後に置いておきます。
この記事の前提: Codex CLI（CLI＝ターミナルで文字を打って操作する方式）を対象にしています。コマンド名・既定の挙動・フラグの値は、記事末尾に挙げたOpenAIの公式ドキュメントと照合しています。
そもそも「承認モード」と「サンドボックス」って何？
いきなり2つ言葉が出てきたので、まずここだけ、ゆっくりいきましょう。Codexの安全のしくみは、役割の違う2枚のガード が組み合わさってできています。
- サンドボックス（sandbox） … Codexが技術的に「何をできるか」を制限する砂場のこと。たとえば「ファイルを書き換えていいのは今の作業フォルダの中だけ」「インターネットには繋がせない」といった、できることの範囲そのもの を決めます。砂場の外には手が出せない、というイメージです。
- 承認ポリシー（approval policy） … Codexが何かをする前に「いつ人間に確認をとるか」を決めるルール。たとえば「作業フォルダの外を触るときは必ず聞いてね」「よく分からないコマンドを流す前は止まってね」といった、確認のタイミング を決めます。
ここ、混ざりやすいので一度だけ整理します。
- サンドボックス＝ できることの広さ（どこまで手を伸ばせるか）
- 承認ポリシー＝ 止まって聞く頻度（どこで人間に確認するか）
この2枚が重なって、はじめて「安心して任せられる状態」ができあがるんです。片方だけだと、片手落ちになる。両方セットで考えるのがコツです。
ついでに、この記事で何度も出てくる言葉も先に定義しておきますね。
- リポジトリ … Gitでバージョン管理されているプロジェクトのフォルダのこと。ざっくり「変更履歴を残せる作業フォルダ」くらいの理解でOKです。
-
ワークスペース … Codexが「書き込んでいい」と見なす範囲。基本は今いるカレントディレクトリと、
/tmpのような一時フォルダが含まれます。
なぜ便利なのか — 「怖さ」を、設定で飼いならせる
結論から言うと、承認モードとサンドボックスが便利なのは、AIの怖さを、自分の手でつまみ（ダイヤル）にできるから です。
AIに開発を任せるときの不安って、突き詰めると「制御できない感じ」なんですよね。何をされるか分からない。だから怖い。
でもCodexは、その「何をされるか」を、あなたが事前に線引きできます。
- 相談だけしたい日は、読むだけ・書き換えさせない に絞る。
- コードをどんどん書かせたい日は、作業フォルダの中は自由、外に出るときだけ確認 にする。
- CIや自動化で回したいときは、一切聞かずに読むだけ にする。
同じCodexなのに、その日のタスクに合わせて「任せる広さ」を変えられる。これって、車のアクセルとブレーキを自分で踏めるのと同じで、制御できるからこそ、安心して速く走れる んです。「AIがすごいから全部任せる」ではなく、「人間が範囲を決めて、その中で思い切り働かせる」。ここが肝かなと思います。
まず全体像 — 覚えるのは、たった3段だけ
細かい設定はたくさんありますが、最初に押さえるべきは 3つのモード だけです。ここさえ分かれば、あとは応用です。
| モード | ざっくり何ができる | こんなときに |
|---|---|---|
| 読むだけ（read-only） | ファイルを読んで質問に答えるだけ。編集もコマンド実行もしない | コードを壊さず相談・調査したい。まず様子を見たい |
| Auto（既定のおすすめ） | 作業フォルダ内の読み書き・コマンド実行は自動。フォルダの外やネット接続は確認をとる | 普段づかい。実装を進めたい。迷ったらこれ |
| フルアクセス（danger-full-access） | サンドボックスも承認もなし。何でもできてしまう | 基本使わない。隔離した環境だけ（後述の反証を必ず読んでください） |
Codexは、あなたが何も指定しなければ Auto で動きます。正確には「作業フォルダ内は書き込みOK・承認は必要なときだけ聞く（on-request）・ネットワークは既定でオフ」という、ちょうどいい真ん中の設定です。
しかも起動時にCodexは、そのフォルダがGit管理されているかを見て、おすすめを変えてくれます。
- バージョン管理されたフォルダ → Auto をおすすめ（変更履歴が残るので戻せるから）
- バージョン管理されていないフォルダ → read-only をおすすめ（戻せないので慎重に）
「戻せるかどうか」で安全側に倒してくれる、という設計思想が透けて見えて、個人的にはここ、けっこう好きなポイントです。
使い方① 起動するときに決める
いちばん基本のやり方は、Codexを起動するコマンドにフラグ（＝オプション指定）を付けることです。使うのはこの2つ。
-
--sandbox… サンドボックスモードを選ぶ。値はread-only/workspace-write/danger-full-access -
--ask-for-approval… 承認のタイミングを選ぶ。値はon-request/untrusted/never（短く-aとも書けます）
たとえば、既定のAutoを明示的に指定するとこうなります。
# Auto（作業フォルダ内は自動、外・ネットは確認）— 実は無指定でもこれ
codex --sandbox workspace-write --ask-for-approval on-request
「今日は読むだけにしたい」ならこう。
# 読むだけ。編集もコマンド実行も、やる前に必ず確認される
codex --sandbox read-only --ask-for-approval on-request
この2つのつまみの組み合わせを、公式ドキュメントは代表的なパターンとして表にまとめてくれています。よく使うものを抜き出すと、こんな感じです。
| やりたいこと | 指定するフラグ | 動き |
|---|---|---|
| Auto（既定） | 無指定 or --sandbox workspace-write --ask-for-approval on-request
|
作業フォルダ内は読み書き・実行OK。フォルダ外やネットは承認が必要 |
| 安全に読むだけ | --sandbox read-only --ask-for-approval on-request |
読んで答えるだけ。編集・実行・ネットは承認が必要 |
| 読むだけ・確認なし（CI向け） | --sandbox read-only --ask-for-approval never |
読むだけ。一切聞かない |
| 編集は自動・あやしいコマンドだけ確認 | --sandbox workspace-write --ask-for-approval untrusted |
読み書きは自動、未信頼のコマンドを流す前だけ承認 |
| フルアクセス（非推奨） |
--dangerously-bypass-approvals-and-sandbox（別名 --yolo） |
サンドボックスも承認もなし |
--ask-for-approval untrusted は、地味だけど便利です。ファイルの読み書きはサクサク自動でやってくれて、状態を壊しかねないコマンド（たとえば破壊的なGit操作など）を流す前だけ、ちゃんと止まって聞いてくれる。「速さ」と「怖い操作だけ確認」のいいとこ取りなんですよね。
なお、承認を一切なしにする --ask-for-approval never は、どのサンドボックスモードとも組み合わせられます。「承認は聞かないけど、サンドボックスの砂場からは出さない」という運用もできる、ということです。ここ、never＝危険、と早合点しがちですが、サンドボックスで囲ったうえでのneverなら、範囲は守られたまま なんです。
使い方② セッションの途中で切り替える — /permissions
「起動したあとで、やっぱり読むだけにしたい」ということ、ありますよね。Codexを立ち上げ直さなくても、会話の途中でモードを変えられます。それが /permissions コマンドです。
Codexが起動している画面で、こう打つだけ。
/permissions
これで今のサンドボックスモードや「書き込んでいい範囲（writable roots）」を確認したり、read-onlyに切り替えたりできます。「今は相談モードにしておこう」と思ったら、/permissions で読むだけに落とす。この気軽さが、実際に使うとありがたいんです。
あわせて覚えておくと便利なのが /status。
/status
これで、今のワークスペースにどのディレクトリが含まれているか が見られます。「Codexが書き込めるのはどこまで？」が一目で分かるので、任せる前の確認にちょうどいいです。
使い方③ 毎回同じにしたいなら、設定ファイルに書く
「毎回フラグを打つのは面倒。いつも同じ設定でいい」という人は、設定ファイル config.toml（場所は ~/.codex/config.toml）に書いておけます。TOML（トムル）は、設定を書くためのシンプルな記法だと思ってください。
# 毎回「確認多め・読むだけ」で始めたい場合の例
approval_policy = "untrusted"
sandbox_mode = "read-only"
# （任意）workspace-writeのときにネットワークを許可したいなら
[sandbox_workspace_write]
network_access = true
-
approval_policy… 承認ポリシー（"on-request"/"untrusted"/"never"など） -
sandbox_mode… サンドボックス（"read-only"/"workspace-write"など）
さらに、用途ごとに設定を「プロファイル」として保存して、起動時に選ぶこともできます。
# 保存しておいたプロファイルを指定して起動
codex --profile readonly_quiet
まとめると、任せる範囲の決め方は3層 で考えると迷いません。
| 決めるタイミング | 使うもの | 向いている場面 |
|---|---|---|
| その場（セッション中） | /permissions |
途中で気が変わった、相談モードにしたい |
| 起動するとき |
--sandbox / --ask-for-approval
|
このタスクだけ設定を変えたい |
| ずっと（恒久化） |
config.toml / --profile
|
いつも同じ設定で始めたい |
最初の1歩 — 10分でできる「安全確認」ハンズオン
言葉だけだとピンと来ないので、実際に手を動かして「任せる範囲を自分で決める」感覚をつかみましょう。壊れて困るコードのない、練習用の空フォルダ でやるのがおすすめです。
# 1. 練習用フォルダを作って、その中へ移動
mkdir codex-permission-practice
cd codex-permission-practice
# 2. （任意）Git管理にしておくと、起動時にAutoがおすすめされる
git init
# 3. Codexを起動（何も指定しなければAutoで立ち上がる）
codex
Codexが立ち上がったら、まずは現状を見てみます。
/status
→ 今どのフォルダが「書き込んでいい範囲」に入っているかが表示されます。「なるほど、この中だけなんだな」と確認できればOKです。
次に、あえて 読むだけモード に切り替えてみましょう。
/permissions
→ ここで read-only を選びます。これで「Codexは読んで答えるだけ。ファイルは書き換えない」状態になりました。試しに「このフォルダに hello.txt を作って」とお願いしてみてください。read-onlyなので、Codexは勝手に作らず、確認を求めてくる はずです。
この「頼んでも、いきなり手を出さずに止まる」——これこそが、あなたが範囲を握れている証拠です。ここまで来たら、承認モードとサンドボックスの本質はもう体で分かっています。
補足: 上のコマンド列は公式ドキュメントの仕様に沿って書いていますが、実際の表示や選択肢はバージョンで少しずつ変わります。手元での通し実行までは本記事では確認していないので、細部は画面の案内に従ってください（動作未確認・公式仕様準拠）。
つまずきポイント / よくある質問
Q. 毎回「これ実行していい？」と聞かれて、正直ちょっと面倒です。
A. それ、あなたがちゃんと安全側にいる証拠です。ずっと確認が多いと感じるなら、--ask-for-approval untrusted にしてみてください。ふつうの読み書きは自動で進み、あやしいコマンドの前だけ止まってくれます。速さと安心の中間で、いちばん現実的かなと思います。
Q. 逆に、何も聞かずに進むのが不安です。
A. Codexが何も聞かずに進むのが不安なら、承認を厳しめにしましょう。--ask-for-approval on-request のまま --sandbox read-only にすれば、編集も実行も、やる前に必ず聞いてきます。「まず読むだけ」から始めて、信頼できたら少しずつ任せる範囲を広げる——この順番が安心です。
Q. Codexがネットにアクセスできなくて、インストール系のコマンドが失敗します。
A. これは不具合ではなく、既定でネットワークがオフだからです。安全のための初期設定です。どうしても必要なときだけ、config.toml の [sandbox_workspace_write] で network_access = true にして開けられますが、開けたら、その分だけ外の世界と繋がる ことは意識しておいてください。
Q. .git フォルダを触ってほしくないのですが。
A. 心配いりません。書き込み可能なワークスペースの中でも、.git や .agents、.codex といったフォルダは 読み取り専用として保護 されています。うっかり履歴を壊されない設計になっています。
Q. --yolo（フルアクセス）って、使っていいんですか？
A. 基本、使わないでください。理由は次の章に書きます。
反証と注意 — ここだけは、正直に
便利な機能ほど、限界とリスクもセットで知っておきたいので、最後に正直なところを書きます。
フルアクセス（--sandbox danger-full-access / --yolo）は、気軽に使うものではありません。 これはサンドボックスも承認も外した状態で、公式でも 「Elevated Risk（高いリスク）」「非推奨」 と明記されています。使うとしても、Dockerやdevコンテナのように 外側でしっかり隔離された環境の中だけ に留めるのが鉄則です。ふだんの自分のPCで、履歴の残る大事なリポジトリに対して、いきなりYOLOで走らせる——これは避けましょう。
そして、そもそも 多くの人にとっては既定のAutoで十分 です。「もっと自由にしないと不便かも」と思う前に、まずAutoで数回使ってみてください。承認プロンプトが出たら、中身のコマンドを1回だけ自分の目で読んでから許可する。 これを習慣にするだけで、任せる感覚はぐっと安定します。
もう一つ大事な限界。サンドボックスはOSの仕組み（macOSのSeatbelt、Linuxのbwrap＋seccompなど）に依存していて、万能ではありません。 Dockerの構成によっては、そもそもサンドボックスがうまく働かないこともあります。さらに、ネットワークやWeb検索を有効にすると、外部のページに紛れ込んだ悪意ある指示（プロンプトインジェクション）をAIが読んでしまうリスクも生まれます。だから「サンドボックスに入れたから絶対安全」ではなく、外部から取り込む情報は基本的に疑う くらいの姿勢がちょうどいいです。
でも、怖がりすぎなくて大丈夫。ここまで読んだあなたは、もう「任せる範囲を自分で決める」つまみを手にしています。怖さは、ゼロにするものじゃなくて、設定で飼いならすもの。 その第一歩を、今日踏み出せたなら十分です。
まとめ
- Codexの安全は、サンドボックス（できることの広さ） と 承認ポリシー（いつ人に聞くか） の2枚で決まる。
- 覚えるのは3段だけ。読むだけ / Auto / フルアクセス。迷ったら Auto。
- 決め方は3層。その場は
/permissions、起動時は--sandbox・--ask-for-approval、恒久化はconfig.toml。 - フルアクセス（
--yolo）は隔離環境だけ。多くの人はAutoで十分。 - まずは練習フォルダで
/status→/permissionsで read-only を体感してみる。
「AIに勝手に動かれるのが怖い」は、設定を知らないときの不安でした。範囲を自分で決められると分かった今、その怖さは、あなたが握れるダイヤルに変わっています。今日はまず、いつものプロジェクトで一度Autoのまま起動して、承認プロンプトの中身を1回だけ、じっくり読んでみてください。それが、AIと安全に付き合う一番いい練習になります。
参考リンク（この記事で実際に読んだ公式ドキュメント）
- Codex CLI 概要 — OpenAI 公式: https://developers.openai.com/codex/cli
- Agent approvals & security（サンドボックス・承認・ネットワーク）— OpenAI 公式: https://developers.openai.com/codex/agent-approvals-security
※ 本文中のフラグ名・既定値・組み合わせ表は上記公式ドキュメント（2026年8月時点）と照合しています。ハンズオンのコマンド列は公式仕様に基づく記載で、手元での通し実行までは本記事では未確認です。表示や選択肢はバージョンにより変わることがあります。
生成AI活用エンジニア＆3児のパパ。AI×開発の実践知を毎日発信しています。X（旧Twitter）でも発信中なので、よければのぞいてみてください → https://x.com/akira_papa_AI