Codex CLI「ネットワーク制限」を2コマンドで解除する方法（2026年）¶
対象 / ポイント
対象: Codex内のnpm・curl・API通信だけがsandboxに拒否される人
ポイント:
workspace-writeのファイル保護は残せるnetwork_access=trueで出向き通信だけを許可できる- 永続設定の前に、1回限りのCLI引数で確認する
ネットワークだけが必要なら、まず次の最小構成を試す。
codex -s workspace-write \
-c 'sandbox_workspace_write.network_access=true'
非対話実行なら次の形にする。
codex exec -a never -s workspace-write \
-c 'sandbox_workspace_write.network_access=true' \
"Run npm install, then run the tests"
先にエラーを見分ける¶
「ネットワークが使えない」ように見えても、すべてが同じ原因ではない。表示された文字列で分ける。
| 表示されるエラー | 主な切り分け先 |
|---|---|
Network access is restricted / sandboxに拒否された | 本記事のnetwork_access設定 |
missing field sandboxPolicy | Browser / Computer Useとnode_replの互換性問題。本記事の設定では直らない |
Reconnecting... / WebSocket timeout | Reconnecting問題の切り分け |
Could not resolve host | DNS、VPN、プロキシ、ホスト側ネットワーク |
HTTP 401 / 403 | API認証または接続先の権限 |
missing field sandboxPolicyなら、node_replのsandboxPolicyエラー対処へ進む。サンドボックスを無効にしても、JavaScript実行前のMCPメタデータ検証で失敗するため解決しない。
一時的にネットワークを許可する¶
まず永続設定を変えず、CLI引数で1回だけ確認する。
codex -a on-request -s workspace-write \
-c 'sandbox_workspace_write.network_access=true'
この組み合わせの役割は別々だ。
-a on-request: 必要な場合は承認を求める-s workspace-write: 書き込み範囲をワークスペースに制限するnetwork_access=true: そのサンドボックスで出向き通信を許可する
ネットワークを許可しても、ファイルサンドボックスを外す必要はない。danger-full-accessへ広げる前に、この最小構成で試す。13
config.tomlへ保存する¶
毎回同じ設定を使う場合だけ、$CODEX_HOME/config.tomlへ保存する。CODEX_HOMEを設定していなければ、通常は~/.codex/config.tomlだ。
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true
承認を出さない非対話処理も既定にするなら、用途を理解したうえで追加する。
approval_policy = "never"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true
CLI引数はconfig.tomlより優先される。設定したのに反映されない場合は、alias、ラッパースクリプト、IDEの起動引数も確認する。
接続先ドメインを限定する¶
ネットワークを許可したうえで接続先を絞りたい場合は、ネットワークプロキシのドメインルールを併用できる。2
[features.network_proxy]
enabled = true
domains = {
"registry.npmjs.org" = "allow",
"api.github.com" = "allow"
}
この設定だけではネットワークは有効にならない。sandbox_workspace_write.network_access = trueも必要だ。未記載のドメインは拒否され、同じ接続先に許可と拒否が重なった場合は拒否が優先される。
設定後もcurlやnpmが失敗する場合¶
ネットワーク許可は、DNS、VPN、プロキシ、証明書、接続先の認証まで直す機能ではない。次の順に確認する。
1. 有効な設定とインストールを確認¶
codex --version
codex doctor --summary
codex --help
Issueへ報告する場合はcodex doctor --jsonを使えるが、出力は共有前に必ず確認する。プロジェクト名やローカルパスなど、公開不要の情報は伏せる。
2. ホスト側でも接続できるか確認¶
curl -I https://api.openai.com
Codexの外でも失敗するなら、サンドボックスではなくホスト側を直す。社内VPN、DNS、SSLインスペクション、プロキシ認証が候補になる。
3. プロキシ環境変数を確認¶
env | rg '^(HTTP|HTTPS|ALL|NO)_PROXY='
プロキシ値や認証情報を記事、Issue、スクリーンショットへ貼らない。特にURL内のユーザー名・パスワードは削除する。
4. 接続先の認証を確認¶
HTTP 401はネットワーク到達後の認証失敗、403は認可やポリシー拒否の可能性が高い。network_access=trueを何度変更しても解決しない。
安全に使うための境界¶
ネットワークを許可すると、依存パッケージの取得、外部API呼び出し、データ送信が可能になる。実行前に次を決めておく。
- ロックファイルを使い、依存関係をレビューする
.envやクラウド認証情報を作業ディレクトリへ置かない- 本番APIではなく、権限を絞った開発用資格情報を使う
- CIでは一時Runnerと最小権限トークンを使う
- 不要になった永続
network_access=trueは戻す
よくある質問¶
-a neverだけでネットワークは使える？
使えるとは限らない。承認ポリシーとネットワーク許可は別設定なので、workspace-writeではnetwork_access=trueを明示する。
danger-full-accessにすれば早い？
ファイル保護まで外れるため、ネットワークだけが目的なら過剰だ。workspace-writeとネットワーク許可の組み合わせを先に使う。
missing field sandboxPolicyもネットワーク設定で直る？
直らない。これはBrowser / Computer Useのnode_replへ渡すMCPメタデータの互換性問題として報告されている。専用の切り分け記事を参照する。
まとめ¶
- 一時設定は
workspace-writeとnetwork_access=trueを組み合わせる - Codex外の
curlも失敗するなら、ホストのDNS・VPN・proxyを先に直す - ファイル保護まで外す
danger-full-accessはネットワークだけの解決策にしない