Codex CLIを入れて最初にぶつかったのは、承認プロンプトではなくnpm installできない問題でした。
ファイルは普通に編集されるのに、依存関係のインストールだけが止まります。しばらくは、npm自体の問題だと思い込んでいました。
結論から書くと、sudoで押し切るべきではありません。
そして、approval（承認）とsandbox（サンドボックス）はまったく別の軸です。この2つを区別できないと、「確かに許可したのに、なぜ動かないのか」という混乱が繰り返されます。
Codex CLIでnpm installできないのはなぜか
workspace-writeはファイルの書き込みを許可しても、ネットワークアクセスは別の設定です。そのためnpm installのようにネットワークが必要なコマンドは、ファイル編集とは別に止まることがあります。
最初は、単にnpmがおかしいのだと思っていました。コードファイルは問題なく編集され続けていたからです。
インストールを終えて実際の作業を回すと、コードの修正は通りました。それなのに、依存関係のインストール段階だけが何度も止まりました。
しばらくはnpmの設定を疑っていました。実際の原因は、サンドボックスのネットワークアクセスの条件でした。
それ以来、「ファイルを書けるか」と「ネットワークを使えるか」は、まったく別の権限として見ています。
公式ドキュメントによると、workspace-writeはファイルシステムへの書き込みとネットワークアクセスを別の境界として扱います（OpenAI公式ドキュメント：Sandbox）。
ただ、正確なconfigのキー名まではドキュメントで確認できませんでした。この記事では「ネットワークアクセスは別の設定で制御される」とだけ書いておきます。
グローバルインストールでEACCESが出たら、sudoを使うべきか
私は使いませんでした。sudoで押し切ると今はインストールできても、その後の権限構造がさらにこじれるのを経験済みだったからです。
このEACCESの件は、インストール初期に起きた別の問題です。
既存のsystem Nodeと、別に入れたNodeのバージョンマネージャーの環境が、1台のマシンに混在していました。そこでグローバルのnpmパッケージを入れようとして、権限の問題が出ました。
最初の反応はsudo npm install -g ...でした。そこで手を止めました。
Nodeのインストールパスを整理し、ユーザー領域のNode環境から入れ直すと、問題は消えました。
この試行錯誤から、EACCESが出たからといって無条件にsudoを使うべきではない、と判断しています。
Codex CLIの承認とサンドボックスは何が違うか
approval_policyはいつ人に確認するかを決め、sandbox_modeは確認せずにどこまで実行できるかを決めます。互いに独立した2つの軸なので、承認を緩めてもサンドボックスの制限は外れません。
この区別を、最初から分かっていたわけではありません。
neverを「全部許可」だと誤解していた
approval_policy = "never"を見たとき、最初は単純に、これで全部自動で許可されるのだと思いました。
実際にはそうではありませんでした。neverにしても、サンドボックスの外の動作は制限されたままでした。
公式ドキュメントにも、--ask-for-approval neverはすべての--sandboxモードと組み合わせて動くよう設計されている、とあります。承認の有無に関係なく、サンドボックスの制限は維持されるという説明です（OpenAI公式ドキュメント：Agent approvals & security）。
2026年9月時点で注意すること
この記事の内容は、2026年9月時点で確認したものです。
Codex CLIは、リリースごとにフラグ名やconfigの値が変わってきた経緯があります。古いチュートリアルのオプション名をそのままコピーすると、最新版と合わないことがあります。
実際、approval_policy = "untrusted"は2026年8月にマージされたPRで廃止されました。0.149.0以降では、この値が残った設定ファイルを読み込むと、起動そのものがエラーで止まります（openai/codex PR #39630）。
現在の公式ドキュメントが明記しているapproval_policyの値は、on-request、never、細かく設定できるgranularの3つです。よく知られている「unless-trusted」という値は確認できませんでした。
そのため、config.tomlを触るたびに、CLIのhelpと公式のconfig referenceを開き直すほうが安全だと考えています。
workspace-writeとdanger-full-access、承認でどれだけ時間が変わるか
同じリファクタリング作業を5回繰り返した私の実測では、workspace-write + on-requestが14〜16分、隔離環境のdanger-full-accessが11〜13分でした。個人の実測で、一般化できる性能値ではありません。
環境は、macOS（Apple Silicon）上の個人/POCリポジトリです。変えた条件は2つだけです。
| 条件 | 所要時間（5回平均の範囲） | 承認の介入 |
|---|---|---|
| workspace-write + on-request | 14〜16分 | 2〜4回 |
| danger-full-access（隔離環境） | 11〜13分 | なし（承認プロンプトは出ない） |
承認の介入2〜4回はどこで起きたか
workspace-write + on-requestでは、1回の作業ごとにだいたい2〜4回、権限の介入がありました。workspace内のファイル修正や通常のテストは、ほぼそのまま進みました。
止まった場面は、ほとんど同じ種類でした。ネットワークアクセスが必要になったときか、workspace外のファイルに触る必要が出たときです。
14〜16分と11〜13分の差を一般化しない理由
同じ作業を隔離環境のdanger-full-accessで回すと、承認で止まる時間はほぼなくなります（上の表を参照）。
ただ、これを「danger-full-accessは20%速い」という一般的な性能値にするつもりはありません。実際の差は、作業中にサンドボックス外へのアクセスがどれだけ必要かに大きく左右されました。
精密なタイムスタンプで測ったわけでもありません。個人で5回繰り返しただけの数字です。
danger-full-accessはどんな環境なら使えるか
Docker、使い捨てのVM、別のworktreeのように、丸ごと捨てられる環境だけで使うのが私の基準です。公式ドキュメントでも、ファイルシステムとネットワークの境界を完全になくすモードと説明されています（OpenAI公式ドキュメント：Sandbox）。
最も保守的なread-onlyモードは、そもそも書き込みを止めるので、この比較では扱っていません。
--dangerously-bypass-approvals-and-sandbox（別名--yolo）のドキュメントでの表記は、「EXTREMELY DANGEROUS」ではなく[Elevated Risk] No sandbox; no approvals (not recommended)です。使用には注意するよう警告もあります（OpenAI公式ドキュメント：Agent approvals & security）。
--sandbox/-sと--profileは、ドキュメントで確認できました。--worktreeや--approve-for-meというフラグは、今回確認した範囲では根拠が見つからなかったので扱いません。
個人リポジトリ・社内POC・自動化の実験、3つの環境の基準
実際には、3つの環境を分けて使っています。
個人リポジトリは、macOSホストでworkspace-write + on-requestです。
社内POCは、開発用リポジトリでworkspace-write中心にしています。credentialとproductionは分離し、そのアクセスはまったく別のツールと環境で扱っています。
リスクの低い自動化の実験だけ、Dockerや使い捨てのworktreeでより広い権限を使います。
デフォルトは、常にworkspace-writeです。
判断基準は速度ではありません。「このエージェントが誤って実行したとき、workspaceの外まで影響が及んでもいいか」です。たいていの場合、答えはノーです。
ホストの普段の開発リポジトリでは、「楽だから」という理由だけでbypassオプションをデフォルトにはしていません。
profileは最小限にしか分けない
profileは作りすぎないようにしています。デフォルト設定は保守的にしておき、隔離環境用のprofileを1つくらい別に管理しています。
Antigravity CLIと比べて、Codexの承認は少なかったか
同じ作業で、Codexのworkspace-write + on-requestのほうがAntigravityより介入が少なく感じました（個人の比較で、ツールや時期によって変わる可能性があります）。Antigravityは承認モードで約18分、自動進行で約12分でした。
| ツール/モード | 所要時間 | 承認回数 | ブロック |
|---|---|---|---|
| Antigravity CLI 承認モード | 約18分 | 6〜7回 | 4件 |
| Antigravity CLI 自動進行 | 約12分 | – | – |
| Codex workspace-write + on-request | 14〜16分 | 2〜4回 | – |
Antigravityで試したときと比べると、Codexのworkspace-write + on-requestでは、workspace内の普通のコマンドまで一つずつ承認している感じはあまりありませんでした。
日常的なコーディングエージェントの用途では、この組み合わせのほうが楽でした。
判断の基準は、当時も今も同じです。blast radius（影響範囲）と、元に戻せるか（reversibility）です。
ただ、サンドボックスと承認を区別できないと、どのツールでも同じように迷う点は共通していました。
Claude Codeの--dangerously-skip-permissionsに、Codexのどの組み合わせが正確に対応するかは、この記事では深入りしません。
私にとってサンドボックスは、エージェントを疑うための機能ではない
モデルがどれだけ良くなっても、モデルの推論とは別の失敗経路は残ります。shellコマンド、パッケージのscript、間違ったパス、予想外のテストのcleanupなどです。
承認のクリックを何回か減らすより、1回のミスのblast radiusをworkspace内に閉じ込めること。それが私のデフォルトです。
参考資料
- OpenAI公式ドキュメント：Sandbox：サンドボックスのモードごとのファイルシステム・ネットワーク境界の区別と、danger-full-accessが境界をなくすことの根拠
- OpenAI公式ドキュメント：Agent approvals & security：approval_policyとsandbox_modeが独立していること、bypassフラグの警告表示、CLIフラグの根拠
- openai/codex PR #39630：Retire the untrusted approval policy：
approval_policy = "untrusted"の廃止と、0.149.0での起動エラーの根拠
この記事は韓国語の原文をもとにローカライズしたものです: https://jjeongil.tistory.com/3566。