Codexで作業していると、コマンドが実行できなかったり通信が遮断されたりすることがあります。
原因の一つはサンドボックスの制限ですが、認証・通信先・プロキシ・設定ミスや不具合でも失敗します。
まずエラー内容と現在の権限を確認します。
Codexの制御は、操作可能な範囲を決めるサンドボックスと、実行前に確認するかを決める承認の2つに分かれています。
この2つは別々に設定します。
この2点を分けて把握すると、原因と対処法を特定しやすくなります。
サンドボックスの3段階
| 設定値 | 動作と権限 |
|---|---|
read-only | 読み取り中心。許可された読み取りコマンドは実行できる。書き込みは制限 |
workspace-write | 作業領域と追加の書き込みルート内を編集可能。保護パスは例外。通信は既定で無効 |
danger-full-access | Codexのサンドボックス制限を外す。OSや管理ポリシー等の制約は別 |
起動時にコマンドライン引数で指定する場合は次のように実行します。
codex --sandbox workspace-write起動時に自動選択される基準
Git管理の有無は起動時の推奨設定に関わります。
ただし、実際の動作は明示した設定・プロファイル・信頼状態・管理ポリシーにも左右されます。
- Git管理下の推奨例 …
workspace-write＋on-request - Git管理外の推奨例 …
read-only
変更できない場合は、read-onlyで起動していないか、対象が書き込み範囲や保護パスに当たらないかを確認してください。
Git管理外であることだけでは原因を特定できません。
作業ディレクトリを信頼済みに設定するまで read-only で動作することもあります。
現在の状態は /status、権限の変更は /permissions で確認・設定できます。
書き込み可能モードでも保護される対象
workspace-write を指定している場合でも、次のパスは読み取り専用として保護されます。
.git.agents.codex
通常のworkspace-writeでは、書き込み可能なルート直下のこれらのパスや .aws も保護されます。
.gitが参照ファイルの場合は、その参照先も対象です。
その他の3つはディレクトリとして存在する場合に保護され、配下にも適用されます。
履歴や設定ファイルが意図せず破損するのを防ぐ仕組みになっています。
承認プロンプトの動作設定
制限された操作や変更を伴う処理を行う際に、ユーザーに確認を求めるかを決めるのが承認設定です。
| 設定値 | 動作 |
|---|---|
on-request | 承認が必要な操作の実行時のみ確認を求める |
untrusted | 廃止された承認値。現在の設定や起動引数には指定しない |
never | 確認を求めない。現在のサンドボックス内で許可された操作のみ実行 |
codex --sandbox workspace-write --ask-for-approval on-requestnever は実行権限を拡張する設定ではありません。
確認プロンプトが表示されなくなるだけで、サンドボックスによる制限自体は維持されます。
この違いを混同すると、「確認は出ないのに処理が失敗する」という状況の原因になります。
ネットワーク通信が失敗する場合の対処
workspace-write では、外部通信が既定で無効化されています。
npm installやpip installはネットワーク制限で失敗することがあります。
ただし依存関係、認証、証明書、配布元の障害もあるため、エラーを読んでから必要な通信だけ許可してください。
通信を許可するには設定ファイルを編集します。
既存のconfig.tomlを残し、同名のセクションがあればその中の値を変更してください。
同じセクションを重複して追加すると、TOMLの読み込みエラーになります。
# ~/.codex/config.toml
[sandbox_workspace_write]
network_access = true通信先のドメインを制限する方法
通信を有効化したうえで、アクセス可能な宛先をホワイトリストで絞り込むことも可能です。
[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }このプロキシが対象とするのは、ローカルのコマンド用サンドボックス内の通信です。
Web検索、アプリ・コネクター、ブラウザー、MCP全体に同じドメイン制限がかかるわけではありません。
宛先ルールを定義しただけでは、通信機能自体は有効化されません。
| 通信設定 | proxy設定 | 実際の挙動 |
|---|---|---|
| 無効 | 有効 | 通信は無効のまま維持。宛先ルールは適用されない |
| 有効 | 無効 | このプロキシによるドメイン絞り込みなし。OS等の制約は別 |
| 有効 | 有効 | 指定したルールに基づいて宛先を制限 |
特定ドメインへのアクセスに絞り込みたい場合は、通信許可とproxy設定の両方を有効にする必要があります。
許可ルールはホスト単位で、example.comを許可してもapi.example.comまで許可されるわけではありません。
*.example.comはサブドメインだけ、**.example.comは元のドメインとサブドメインが対象になり、denyはallowより優先されます。
Web検索機能の独立設定
コマンド実行時の外部通信とは別に、Web検索機能にも個別の設定項目があります。
web_searchはconfig.tomlのトップレベルに書くため、[sandbox_workspace_write]や[features.network_proxy]などのセクションより前に置いてください。
web_search = "cached" # 既定。あらかじめ集めた結果を使う
# web_search = "live" # その場で見に行く（--search と同じ）
# web_search = "disabled" # 使わない既定値が cached に設定されているのは、取得したWebコンテンツ経由で意図しないプロンプト指示が混入するリスクを低減するためです。
最新情報が必要ならliveを選びます。
Full accessではliveが既定になる場合があり、cachedでも取得内容を無条件に信用できるわけではありません。
ユースケース別の推奨設定
| 用途 | 推奨コマンド引数 |
|---|---|
| 通常開発 | --sandbox workspace-write --ask-for-approval on-request |
| コード閲覧・設計相談 | --sandbox read-only --ask-for-approval on-request |
| CI環境での読み取り専用実行 | --sandbox read-only --ask-for-approval never |
| 旧untrusted設定の移行 | 下記の公式移行資料を確認。現在は承認値として指定しない |
以下はローカルCLIで従来のsandbox_mode設定を使う例です。
通信が必要な場合にnetwork_accessを有効にします。
新しい権限プロファイルを使う場合は別の構成になるため、両方式を同じセッションで混在させず、公式資料で適用元を確認してください。
# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true用途ごとに設定を切り替える場合はプロファイル機能を活用します。
# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"codex --profile full_auto のようにプロファイル名を指定して呼び出せます。
すべての制限を解除する指定
次はCodexのサンドボックスを解除し、承認プロンプトも出さない組合せです。
OSや組織ポリシー、外部サービス側の権限まで解除するものではありません。
codex --sandbox danger-full-access --ask-for-approval never--dangerously-bypass-approvals-and-sandbox も同様の目的で使用される指定です。
セキュリティリスクが高いため、開発環境のホストマシンで常用する設定ではありません。
検証用コンテナなど、システムが破損しても問題のない隔離環境に限定して使用してください。
よくあるトラブルと解決策
ファイルが書き換えられない
/statusで現在の設定を確認し、対象パス、信頼状態、OSの書き込み権限、管理ポリシーを切り分けます。
必要な書き込み範囲を確認してから /permissions で変更します。
権限エラーを直す目的だけで、既存フォルダーを新しいGitリポジトリにする必要はありません。
承認を無効化したのにコマンドが失敗する
--ask-for-approval never は確認プロンプトを省略する設定にすぎません。
失敗理由を確認し、必要なパスや通信先だけ許可する方法を検討します。
サンドボックス全体の解除を最初の対処にはしません。
ドメインを許可しても通信できない
network_access = true が正しく設定されているか確認してください。
proxyルールを設定しただけでは外部通信自体は有効になりません。
プロキシが有効な場合、localhostやプライベートIPへの通信も既定では制限されます。
ローカルの接続先が必要なら、対象のlocalhostやIPアドレスを明示的なallowルールとして追加する方法を確認してください。
ワイルドカードの許可だけではローカル宛先の例外にならず、ホスト名がプライベートIPに解決される場合も別の制約があります。
プロジェクト設定が反映されない
.codex/config.toml は、対象プロジェクトが信頼済みとして登録されるまで読み込まれません。
クローン直後などの未信頼リポジトリでは設定が無効化されます。
この記事で紹介しているコードは、GitHubのMOTOKI-LLC/cg-method-codeにもまとめています。
導入と設定の記事は、ほかにもあります。
要点まとめ
- サンドボックス（操作可能範囲）と承認（確認タイミング）は独立した設定である
- Git管理の有無は推奨設定に関わる。実際の設定は
/statusで確認する .git.agents.codexは書き込み可能モード下でも読み取り専用として保護される- 通信は既定で遮断。宛先ルールを記述しただけでは通信は有効にならない
- Web検索は通常
cached。Full accessでは既定がliveになる場合がある
Codex CLIのインストール手順や設定ファイルの配置場所は、Codex CLIのインストールと初期設定にて詳しく解説しています。
同様のパーミッション管理設計はClaude Codeにも採用されています。
Claude Codeの権限設定については、Claude Code│権限設定の使い方をご覧ください。
2026年10月27日に公式の承認・セキュリティ資料と権限プロファイル資料を再照合しました。
手元のCLI 0.160.0のhelpでは承認値はon-requestとneverです。
掲載例の実行・遮断試験は今回行っていません。
設定項目名や仕様はアップデートにより変更される可能性があるため、最新の公式ドキュメントも併せて確認してください。
よくある質問：Codexのサンドボックスと承認
Codexでコマンドが実行できない、通信が遮断されるのは、不具合ですか？
サンドボックスが原因の場合もありますが、認証・DNS・プロキシ・通信先の障害なども考えられます。
失敗だけで原因は断定できません。
Codexの制御は、操作可能な範囲を決めるサンドボックスと、実行前に確認するかを決める承認の2つに分かれていて、別々に設定します。
この2点を分けて把握すると、原因と対処法を特定しやすくなります。
サンドボックスの3段階は、どう違いますか？
read-only（読み取り中心。許可された読み取りコマンドは実行できる。書き込みは制限）、workspace-write（書き込み可能なルート内を編集可能。保護パスは例外で、通信は既定で無効）、danger-full-access（Codexのサンドボックス制限を外す。OSや管理ポリシー等の制約は別）です。
起動時にコマンドライン引数で指定できます。
ファイルを変更してくれないのは、なぜですか？
Git管理の有無は推奨設定の判断材料です。
明示設定、信頼状態、管理ポリシーを含め、現在の有効な権限を確認します。
公式の推奨例はGit管理下でworkspace-write＋on-request、Git管理外でread-onlyです。
すべての環境で強制される切替ではありません。
read-only、未信頼プロジェクト、保護対象パス、OS側の権限などを確認してください。
Git管理外であることだけが原因ではありません。
/statusと/permissionsで確認してください。
Gitの初期化を権限問題の万能な解決策にはしません。
workspace-write でも、書き換えられない場所はありますか？
通常のworkspace-writeでは、書き込み可能ルートの.gitと、ディレクトリとして存在する.agents・.codex・.awsが保護対象です。
.gitが参照ファイルなら参照先も保護されます。
履歴や設定ファイルが意図せず破損するのを防ぐ仕組みです。
承認の設定値は、どう違いますか？ never にすれば、何でもできますか？
on-request は、承認が必要な操作の実行時のみ確認を求めます。
現在の approval_policy = "untrusted" は廃止され、起動を妨げる場合があります。
プロジェクトの trust_level = "untrusted" は別の設定です。
移行時は公式資料を確認してください。
never は、確認を求めず、現在のサンドボックス内で許可された操作のみ実行します。
never は実行権限を拡張する設定ではなく、確認プロンプトが表示されなくなるだけで、サンドボックスによる制限自体は維持されます。
この違いを混同すると、「確認は出ないのに処理が失敗する」原因になります。
必要なパス・通信先だけを追加できるか確認してください。
サンドボックス全体の解除で対処する必要があるとは限りません。
npm install や pip install が、エラーになるのは？ 通信を許可するには？
workspace-writeの既定のネットワーク制限が原因の場合があります。
認証・証明書・配布元・依存関係のエラーとの切り分けが先です。
通信を許可するには、設定ファイルを編集します（network_access = true が正しく設定されているかを確認します）。
通信先を絞りたいときは、宛先ルール（ホワイトリスト）を定義しますが、宛先ルールを定義しただけでは通信機能自体は有効になりません。
通信設定が無効なら、proxy設定が有効でも通信は無効のままで、特定ドメインに絞るには、通信許可とproxy設定の両方を有効にします。
Web検索は、どう設定されていますか？
コマンド実行時の外部通信とは別に、Web検索機能にも個別の設定があり、通常はcachedです。
Full accessではliveが既定になる場合があります。
取得したWebコンテンツ経由で、意図しないプロンプト指示が混入するリスクを低減するためで、最新のWeb情報が必要な場面に限定して live を指定するのが安全です。
用途別の推奨設定と、制限をすべて解除するオプションの注意点は？ プロジェクトの設定が効かないときは？
通常開発は --sandbox workspace-write --ask-for-approval on-request、閲覧中心なら --sandbox read-only --ask-for-approval on-request、承認できない読み取り用途なら --sandbox read-only --ask-for-approval never が例です。
廃止された --ask-for-approval untrusted は使いません。
毎回の指定を省くには、設定ファイルに書いて永続化し、用途ごとに切り替えるときはプロファイル機能（codex --profile プロファイル名）を使います。
読み書き・外部通信・承認の制限をすべて解除するオプションもありますが、普段使いのマシンで常用する設定ではなく、検証用コンテナなど、システムが破損しても問題のない隔離環境に限定します。
.codex/config.toml は、対象プロジェクトが信頼済みとして登録されるまで読み込まれず、クローン直後などの未信頼リポジトリでは設定が無効化されます。
なお、記事の内容は変わることがあるので、最新は公式ドキュメントで確認してください。
