network_access設定とCodexの接続エラーを切り分ける方法

network_accessは何を変える設定か

Codex CLIの実行環境は、ファイルに触れる範囲と外部へ通信できる範囲を分けて考えます。read-only は対象を読むことが中心で、workspace-write は指定された作業場所へ変更を書き込めるモードです。danger-full-access はこの境界を大きく外すため、便利さだけを理由に選ぶのではなく、対象と影響を理解したうえで使う必要があります。今回の主役である network_access は、workspace-write のネットワーク制限を変更するための値です。

公式リポジトリの設定ソースでは、SandboxWorkspaceWrite に network_access が含まれ、真偽値に応じてネットワークポリシーが有効または制限として組み立てられています。つまり、設定の置き場所はトップレベルに適当に書くのではなく、[sandbox_workspace_write] の中です。設定項目の名前を間違える、テーブルを一つ上に置く、別のモードと組み合わせると、書いたつもりでも期待した動作になりません。詳細は openai/codexのconfig_toml.rs で確認できます。

ここで大切なのは、ネットワークを許可しても作業場所の書き込み範囲が広がるわけではないことです。反対に、ネットワークを制限していても、ローカルにすでにあるファイルを読める場合があります。どの範囲を変えたいのかを「外部接続」「ファイル変更」「承認」の三つに分ければ、過剰な設定変更を避けられます。OpenAI公式の Codex Security も、サンドボックスと承認を別の安全境界として案内しています。

ファイル範囲と外部接続を分けて考える

たとえば依存パッケージの情報を取得したいだけなら、必要なのは外部接続であって、作業場所の外へ書き込む権限ではありません。workspace-write と network_access = true の組み合わせは、この二つを分けたいときの候補になります。ただし、ネットワークが使えると、実行するコマンドが外部へ送る内容まで自動的に安全になるわけではありません。対象リポジトリ、実行するコマンド、接続先を確認してから使います。

逆に、接続先だけを許可したい場合は、ネットワークを有効にした事実だけで十分と判断しないことが必要です。公式Discussionでも、ネットワークプロキシや接続先の制限を別に考える必要があると説明されています。Codexの版や画面によって設定の効き方が異なる可能性もあるため、CLI、デスクトップアプリ、IDE拡張を同じ挙動だと決めつけず、実際の入口ごとに確認します。

承認ポリシーとは役割が違う

approval_policy は、コマンドを実行するときに確認を求めるかどうかを決める値です。一方の network_access は、サンドボックス内からネットワークへ到達できるかを決めます。承認を never に変えても、ネットワークが制限されたままなら接続は成功しません。反対に、ネットワークを有効にしても、実行操作の確認が必要な構成はあり得ます。

この違いを知らないと、接続に失敗したときに承認を下げ続ける、あるいは広い権限へ切り替え続けることになります。まず通信の有無、次に対象サービスの応答、最後に認証や権限を確認する順序なら、変更する設定を最小限にできます。設定を変えたときは、どの値を変えたかと、どの確認が通ったかを残しておくと戻しやすくなります。

なぜ接続エラーが認証エラーに見えるのか

外部サービスへ接続する処理は、名前解決、TCP接続、TLS、HTTP応答、サービス側の認証という順序で進みます。最初の名前解決で止まっているのに、呼び出したCLIが「ログインできない」「認証情報が無効」と表示することがあります。エラー文は、失敗した層を正確に表すとは限りません。特に workspace-write でネットワークが制限されていると、端末の外側では正常な設定でも、Codexから見た接続だけが失敗します。

openai/codexの Discussion #42402 では、GitHubへ到達できない状態が認証失敗のように報告された事例が説明されています。そこでは、認証情報を変えても結果が変わらないことが通信経路を疑う手掛かりになっています。これはすべての環境で同じ表示になるという意味ではありませんが、認証の前に通信を検査する順序を示す実例です。

Step 1: 失敗地点を文字列で切り分ける

最初に、Codexが返した文面を「名前解決」「接続」「HTTP応答」「認証」のどれに近いか分けます。Could not resolve、timeout、connection refused のような文面なら、まずネットワーク層を確認します。401 や 403 のようなHTTP応答まで返っているなら、少なくとも相手先には届いています。最初から認証情報を更新せず、失敗した文字列と実行入口を記録するのが出発点です。

この作業では、入力した認証情報そのものを記録したり、記事やログへ貼り付けたりする必要はありません。必要なのは、どのホストへ接続したか、HTTPの状態が返ったか、同じ操作をCodexの外で行うと結果が違うか、という分類です。値を見せずに状態だけを残せば、原因を絞りながら情報の露出を増やさずに済みます。

Step 2: 認証なしでネットワーク到達性を確認する

次に、認証を伴わない公開エンドポイントへ、Codexの実行環境から接続できるかを確認します。GitHubのレート制限エンドポイントを例にするなら、次のようにネットワーク許可を一時指定して、HTTP状態だけを返す依頼にします。

codex exec -s workspace-write -c sandbox_workspace_write.network_access=true \
  "run: curl -s -o /dev/null -w '%{http_code}' https://api.github.com/rate_limit"

この確認は、認証が成功したことを証明するものではありません。200 などのHTTP状態が返れば、少なくとも名前解決からHTTPS応答まで進んだと判断できます。名前解決に失敗する、応答が返らない、プロキシで拒否される場合は、認証の確認へ進む前にネットワーク設定や実行入口を調べます。コマンドの構文やCLIの入口は Codex CLI公式ドキュメント と照合してください。

Step 3: 対象サービスの応答を確認する

公開エンドポイントへ届いた後で、実際に使いたいパッケージレジストリやGitHubの対象URLへ接続します。ここでも、まず状態コード、応答時間、名前解決の成否だけを見ます。特定のサービスだけが失敗するなら、プロキシ、DNS、社内ネットワーク、相手側の制限など、対象固有の問題が考えられます。すべての接続が失敗するなら、network_access が有効になっているか、別の実行入口が設定を読んでいるかを戻って確認します。

ここで一つのURLだけに依存しないことも大切です。GitHubが応答しても、社内レジストリや別のAPIが同じ経路で使えるとは限りません。読者が自分の環境で再現できるよう、確認対象、確認日時、結果の状態を分けて記録します。記事の確認日時である 2026-09-23 と、実際に読者が操作する日時は異なるため、固定的な「正常」を約束せず、公式の状態ページや対象サービスの案内も照合します。

Step 4: 最後に認証と権限を確認する

ネットワーク到達性と対象サービスの応答が確認できたら、初めてログイン状態、リポジトリへの権限、利用者の契約範囲などを調べます。ここまで進んで 401 や 403 が返るなら、認証や権限が原因である可能性が高くなります。反対に、通信確認を通さずに認証情報を入れ替えても、ネットワーク未接続の問題は解消しません。

確認時は、認証情報をコマンドライン引数や本文へ直書きしないことが重要です。どのアカウントを使っているかは識別子だけで記録し、値そのものは表示しません。複数のサービスを使う場合も、接続確認と認証確認をサービスごとに分けると、ひとつの失敗を全体の設定問題と誤認しにくくなります。

config.tomlでnetwork_accessを設定する

毎回の確認でCLI引数を付ける方法は、短い検証には便利です。普段の設定として保存するなら、Codexの設定ファイルに sandbox_mode と [sandbox_workspace_write] を分けて書きます。基本形は次のとおりです。

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

[sandbox_workspace_write]
network_access = true

この例では、作業場所への書き込みを許可しつつ、ネットワークを有効にし、コマンドの確認は必要に応じて求めます。approval_policy は利用環境の方針に合わせて検討しますが、値を変えたこととネットワークが有効になることを同じ意味で扱わないでください。設定キーの名称や有効な置き場所は版によって変わる可能性があるため、 Codexの設定リファレンス と現在の公式リポジトリを確認します。

設定ファイルの置き場所を確認する

Codex CLIのユーザー設定は、一般にホームディレクトリ下の .codex/config.toml が起点です。Windowsではユーザーホームの解決方法や、PowerShellから起動したCLIとデスクトップアプリが見る設定の範囲が異なる場合があります。設定を書いた後は、同じ入口、同じ作業場所、同じサンドボックスモードで確認してください。別の入口で試して結果が違っても、すぐに設定値の誤りと断定しないことが大切です。

ファイルを編集したら、まず network_access の表記、角括弧のテーブル名、値の型を確認します。true は文字列ではなく真偽値として書き、同じキーを複数の場所へ重ねて置かないようにします。設定を変更する前の内容を人が読める形で控えておけば、原因確認後に元へ戻す判断もしやすくなります。

CLI引数で一時的に確認する

設定ファイルを変える前に、-c sandbox_workspace_write.network_access=true を使って一回だけ挙動を比べる方法があります。サンドボックスモードも同じ条件にそろえ、外部接続の確認が終わったら、元のコマンドと結果を比較します。これにより、永続設定の読み込み失敗と、ネットワークそのものの制限を分けて見られます。

一時指定で成功し、設定ファイルでは失敗するなら、記述場所、設定の優先順位、起動しているCodexの入口を確認します。一時指定でも失敗するなら、DNS、プロキシ、Windowsのサンドボックス、対象サービスの状態など別の層を調べます。差分を一つずつ作ることが、原因を追うときの基本です。

network_accessを有効にしても接続先を限定したい場合

ネットワークを有効にすることと、特定のホストだけへ接続できることは同じではありません。公式Discussionでは、ネットワークプロキシを設定しない状態では外向き通信の範囲が広くなり得ること、接続先の規則だけではネットワーク許可そのものにならないことが指摘されています。必要な接続先が少ない場合は、会社や家庭のネットワーク側のプロキシ・許可リストと合わせて、どこまで到達できるかを確認します。

ここで重要なのは、許可リストの存在を想像で補わないことです。許可リストを置いたから安全、特定のドメインだけだから十分、と判断せず、実際に許可された接続と拒否された接続を状態だけで検証します。Codexのバージョン更新で設定名や適用範囲が変わる可能性があるため、 公式Changelog と設定リファレンスを更新時に見直します。

Windows・アプリ・WSLで変わる確認ポイント

Windowsでは、ホストのPowerShellで通信できることと、Codexが起動したサンドボックス内から通信できることが一致しない場合があります。Windows版Codexのサンドボックス設定、WSL2のネットワーク、デスクトップアプリとCLIの実装差が、それぞれ別の境界になります。まずどの入口から起動したか、どのシェルがコマンドを実行したか、どのモードが選ばれたかを記録します。

公式リポジトリには、デスクトップアプリとCLIで [sandbox_workspace_write] network_access = true の扱いが一致しないという報告があります。Issue #13373 はアプリ側の挙動についての報告であり、すべての版の仕様を保証する文書ではありません。ただし、同じ config.toml を使っているから同じ結果になると決めつけず、入口ごとに検証する理由になります。

WindowsのホストとCodex内を分ける

ホストのPowerShellで curl やパッケージマネージャーが動いても、Codexの実行環境で同じ名前解決ができるとは限りません。ホスト側の確認結果は「PCの外向き通信が可能」という情報で、Codex側の結果は「選んだサンドボックスから同じ通信が可能」という情報です。両方を別の時刻、別の入口として記録し、片方の成功をもう片方の証拠にしないようにします。

Windows版のネットワーク問題については、公式リポジトリの Issue #18675 に、workspace-write、ネットワーク有効、フルアクセスなどを比較した報告があります。Issueは個別環境の報告なので、記載された回避策をそのまま採用するのではなく、使っている版、サンドボックスの種類、シェル、プロキシの有無が一致するかを確認してください。

デスクトップアプリとCLIを同じ結果と考えない

アプリから同じプロジェクトを開いているように見えても、設定の読み込み時点や権限の適用方法がCLIと異なる可能性があります。CLIで一時指定が成功したのにアプリで失敗するなら、まずCLIの成功を基準にして、アプリ側の設定画面、版番号、再起動後の状態を確認します。逆の場合も同様で、アプリの成功だけをCLIの設定が正しい証拠にはしません。

同じ作業を二つの入口で試す場合は、接続先、コマンド、作業場所をそろえます。途中で認証情報、モデル、ファイル範囲まで変えると、どの差が結果を変えたのか分からなくなります。入口の違いだけを変数にした小さな比較にすれば、調査範囲を広げずに済みます。

WSL2ではWindows側への到達も確認する

WSL2を使う場合、Linux環境からインターネットへ出られることと、Windows側のコマンドやファイルへ到達できることは別の問題です。openai/codexの Issue #43764 では、ネットワーク有効化とWindows相互運用の範囲に関する報告があります。これは個別の問題提起であり、すべての環境で同じ影響が出ると断定できませんが、network_access を単なるDNS設定とみなさないための注意材料になります。

WSL2では、Linux側の名前解決、Windows側のプロキシ、Codexが実行するシェルの種類を順番に確認します。Windowsの資格情報や外部接続を必要以上に広げないため、接続先と作業場所を明確にしたうえで、必要なテストだけを行います。問題が再現したら、Windowsネイティブ、WSL2、デスクトップアプリを混ぜずに一つずつ結果を残します。

設定変更後に残す確認記録

ネットワーク設定は、一度つながれば終わりではありません。Codexの更新、OSの更新、社内プロキシの変更、アプリとCLIの入口変更で結果が変わる可能性があります。次に同じ問題が起きたときに再調査を短くするには、認証情報を残すのではなく、実行条件と通信状態を残します。これは不具合を断定するためではなく、同じ条件をもう一度作るための記録です。版番号だけでなく、接続先、モード、設定も一緒に残し、結果を再現できる記録にします。

Step 5: 変更前後を同じ条件で比べる

変更前に、Codexの版、入口、OS、作業場所、サンドボックスモード、network_access の値、接続先を記録します。変更後は同じ順序で、公開エンドポイント、対象サービス、必要な認証確認を行います。結果が変わったとしても、ネットワーク許可だけが原因とは限らないため、他の条件を固定して比べます。

記録は、成功・失敗の二択だけでなく、DNSまで進んだか、HTTP状態が返ったか、認証で拒否されたかに分けます。たとえば「接続不可」ではなく「ホスト名を解決できない」「HTTPSは返るが403」「対象レジストリだけ応答なし」と書けば、次回に同じ層から調べられます。値そのものを含めず状態だけを保存するのが安全です。

設定を広げる前に小さな確認をする

外部接続が必要な作業でも、最初から大きなビルドや多数の依存取得を行う必要はありません。公開エンドポイントへの到達、対象ホストの応答、必要な一つの読み取り操作の順に小さく確認します。変更対象のファイルを増やさずに接続だけを見ることで、ネットワークの問題と作業内容の問題を分離できます。

失敗した場合は、すぐにフルアクセスへ移るのではなく、設定のテーブル名、CLI引数の優先、入口の違い、WindowsやWSL2の境界を戻って見直します。広い権限で成功しても、なぜ狭い設定で失敗したのかが分からなければ、次の作業で同じ問題を繰り返します。成功条件と必要な範囲を先に言葉にしておくことが、余計な設定変更を防ぎます。

接続先を記録し、不要な許可を残さない

依存パッケージの取得、GitHubの参照、社内APIへの問い合わせでは、必要な接続先が異なります。作業が終わった後も広いネットワーク許可を残す必要があるか、設定を戻せるかを確認します。戻す場合は network_access = false または該当設定を削除し、同じ小さな到達確認で意図した制限に戻ったことを確かめます。

ネットワークを使わない作業まで同じ設定で実行し続けると、原因調査の条件が複雑になります。用途ごとに設定を分ける場合も、名前から意味が分かるようにし、どの場面でどの値を使ったかを記録します。設定の共有時には認証情報や個人の環境値を含めず、モード、到達性、確認日時だけを伝えると再現性と安全性のバランスを取りやすくなります。

よくある間違いと直し方

network_access の調査では、同じ言葉を別の意味で扱うことから誤りが始まります。ネットワークを有効にする設定、実行を承認する設定、サービスへログインする設定はそれぞれ役割が違います。三つを同時に変えず、通信の層から順番に確認することが、もっとも再現しやすい切り分けになります。設定を書いたことと、実行中の入口がその設定を適用したことも別に確認します。小さな比較を積み重ねれば、必要以上に権限を広げずに原因を絞れます。

approval_policyだけを変更する

承認確認が表示されなくなっても、サンドボックスのネットワーク制限が解除されたとは限りません。approval_policy は確認の扱い、network_access は外部接続の扱いです。両方を変更した場合は、どちらの変更で結果が変わったか比較できません。まず元の承認方針を保ったまま、通信だけを調べるのが安全です。

network_accessをテーブルの外へ置く

network_access = true を設定ファイルの先頭に置くだけでは、期待した場所へ適用されない可能性があります。公式ソースで示される SandboxWorkspaceWrite に対応する [sandbox_workspace_write] の中へ書き、sandbox_mode = "workspace-write" との組み合わせを確認します。書いた文字列があることではなく、実行中のCodexがその設定を読んでいることを検証してください。

ホスト側の成功をCodex側の証拠にする

WindowsのPowerShellやWSLの別シェルで成功した結果は、Codexのサンドボックス内で成功する証拠ではありません。逆に、CodexのCLIで成功しても、アプリの同じプロジェクトで成功するとは限りません。入口と実行環境を記録し、同じコマンドを同じ場所から実行した結果だけを比較します。

公開情報がないまま認証情報を入れ替える

ネットワーク未接続、サービス障害、認証失敗は、表示上似ることがあります。公開エンドポイントへの到達とHTTP応答を先に見れば、認証情報をむやみに変更せずに済みます。認証確認へ進むときも、値を表示せず、アカウント識別子と応答状態だけを記録します。

network_accessに関するよくある質問

この設定については、ネットワークが有効になる範囲と、接続エラーの原因をどう分けるかがよく問われます。以下では、実際に確認するときに混同しやすい点を短く整理します。版や入口が異なると結果も変わるため、公式文書とリポジトリの報告を合わせて読み、手元の確認結果と公表仕様を分けて扱ってください。表示された文面だけで原因を決めず、通信と認証を別々に確かめるのが基本です。設定の有効範囲を理解してから、手元の版と入口に合わせて読み進めてください。

network_access = trueならフルアクセスですか？

いいえ。少なくとも設定の意味としては、workspace-write のネットワークポリシーを有効にする値です。作業場所の書き込み範囲、読み取り範囲、コマンド承認、接続先の制限は別に考えます。ただし、外部接続が広がることで取得・送信できる情報の範囲は変わるため、必要な作業場所と接続先を確認してから使います。

承認を求めない設定にすれば接続できますか？

接続できるとは限りません。承認の確認を減らしても、ネットワークが制限されていればDNSやHTTPSへ到達しない場合があります。まず認証なしの到達確認、次に対象サービスの応答、その後に認証と権限の順で調べます。承認とネットワークを別の設定として扱えば、必要以上に広い権限へ移る理由を減らせます。

CLIで成功してアプリで失敗するのは設定ミスですか？

設定ミスとは限りません。公式リポジトリには、同じ設定値でもCLIとデスクトップアプリでネットワークの扱いが一致しないという個別報告があります。使っている版、設定を読んだ入口、実行シェル、サンドボックスの状態をそろえて比較し、Issueや公式Changelogに同じ現象がないか確認してください。

どの公式情報を見ればよいですか？

まず Codex Security でサンドボックスと承認の考え方を確認し、Codex CLI と 設定リファレンス で現在の書式を照合します。設定の実装上の適用範囲は openai/codexのconfig_toml.rs を、直近の事例は Discussion #42402 を参照できます。

まとめ

network_access は、Codexの作業場所と外部接続を切り分けるための設定です。workspace-write を使いながら外部接続が必要な場面では候補になりますが、承認ポリシーや認証情報を同時に変える設定ではありません。まず設定のテーブル名とモードを確認し、実行入口がCLIなのかアプリなのかを記録します。

接続トラブルでは、認証より先に名前解決、HTTPS、HTTP応答を確認します。ネットワークに届いていない状態で認証情報を入れ替えても原因は残ります。公開エンドポイントで通信を確認し、対象サービスへ進み、最後に認証と権限を調べる順番なら、変更範囲を小さく保てます。

2026年9月23日時点で確認できる公式資料とopenai/codexの報告は、workspace-write の初期ネットワーク制限と、接続失敗が別のエラーに見える問題を考える材料になります。版や入口が変わったら、同じ条件で小さく再確認し、Codexの公式セキュリティ文書、CLI文書、設定リファレンス、公式リポジトリの更新履歴を照合してください。