Codex CLI 推奨スペック｜GPU不要でも要注意なローカルサンドボックスとWindows・Node.js環境

Codex CLI は、ターミナルから使う OpenAI の AI コーディングエージェントです。導入前にまず気になるのが「どんな PC で動くのか」でしょう。

結論から言うと、ChatGPT アカウントまたは API キーで OpenAI のモデルを使う通常運用では、モデル推論は OpenAI のクラウド側で行われます。一方、ファイル編集やコマンド実行は手元の環境で行われるため、専用 GPU を積む必要はありません（推論がクラウドのため）。専用 GPU を搭載していない一般的な開発用 PC でも利用できます（後述のとおり、ローカルモデルを使う --oss モードは例外です）。

クラウド型の AI コーディングツール全般に共通する「GPU は不要、効いてくるのは RAM・SSD・回線」という基本のマシン選びは、Claude Code を題材に別記事（Claude Code 推奨スペック）で予算帯まで含めて整理しています。一般的な PC 選びを知りたい方は先にそちらを読むと早いはずです。本記事はその共通部分を前提に、Codex CLI に固有の環境要件——ローカルでコードを動かすサンドボックス、Windows 対応、Node.js まわり、認証——に絞って掘り下げます。

この記事の要点

・ChatGPT アカウントまたは API キーで OpenAI のモデルを使う通常運用では専用 GPU は不要。RAM・Node.js の必要値は導入時に公式配布情報で確認（16GB 以上は Codex 固有の公式要件ではなく、エディタ・ブラウザ・コンテナ併用時の筆者目安）
・Codex 固有の要点は、ローカルでコードを実行するサンドボックスと承認ポリシーの二層構造。信頼済みのバージョン管理フォルダでは Auto（workspace-write＋on-request）が標準で、Auto 構成ではネットワークは既定で無効
・導入は公式インストーラー / npm / Homebrew / GitHub Releases。npm 方式は Node.js が必要（必要バージョンは導入時に公式配布情報で確認）
・Windows はネイティブ sandbox が公式の既定推奨（Windows 11 推奨）、WSL2 は Linux 環境が必要な場合などの選択肢
・Codex は Free を含む各 ChatGPT プランで利用でき、API キー利用時は標準 API 料金が適用され一部のクラウド機能が制限される

OpenAI モデル利用時はクラウド実行｜GPU が要らない理由
Codex 固有①｜ローカル実行サンドボックスと承認モード
1. 3 つのサンドボックスモード
2. 承認ポリシーは別レイヤー
Codex 固有②｜Node.js・Git・インストール経路
1. OpenAI モデル利用時の認証は codex login で行う
2. つまずいたら codex doctor
Windows で動かすときの注意点
ChatGPT アカウントと API キー｜認証と料金
Claude Code とのスペック観点・早見表
まとめ
よくある質問（FAQ）
参考資料

OpenAI モデル利用時はクラウド実行｜GPU が要らない理由

ChatGPT アカウントまたは API キーで OpenAI のモデルを使う通常運用では、Codex CLI はプロンプトとコードの文脈を OpenAI のサーバーへ送り、生成・推論はクラウド側で行います。手元でモデルを動かすわけではないので、画像生成やローカル LLM のようにローカルで VRAM を要求しません。クラウド型のコーディング支援ツールとして、専用 GPU を前提にしない使い方ができます。

そのため、体感に効くのは GPU ではなく次の 3 つです。第一に RAM。最低・推奨値は配布版で更新され得るため、導入時点の公式配布情報を確認するのが確実です。実務としてエディタ・ターミナル・ブラウザ・コンテナや複数の開発ツールを同時に使うなら、16GB 以上を選ぶと余裕を持ちやすいでしょう。第二に SSD。リポジトリの読み書きや依存関係の展開、ビルド・テストなど一般的な開発作業の待ち時間に効きます（Codex 固有の公式 SSD 要件ではなく、開発環境全体の目安です）。第三にネットワーク。応答はクラウド往復なので、回線の安定性と遅延が待ち時間を左右します。加えて、ビルドやテストを重く回すプロジェクトでは CPU も開発環境全体の待ち時間に影響します。

ただし、Codex CLI には --oss でローカルモデルプロバイダーを使う選択肢もあり、公式ドキュメントでは Ollama や LM Studio が例示されています。この場合はクラウドではなく手元でモデルを推論するため、使用するモデルに応じて GPU や RAM など別のハードウェア要件を検討する必要があります。本記事で「GPU 不要」と言っているのは、あくまで OpenAI のクラウドモデルを使う通常運用での話です。なお --oss でも、Web 検索・テレメトリ・認証や更新の経路など設定次第で外部通信は残り得るため、「完全オフライン・外部送信なし」を前提にする場合はこれらを個別に確認してください。

ここまでの基本は Claude Code とおおむね近く、機種選びや予算帯の具体は上記の Claude Code 推奨スペックの記事に譲ります。逆に「クラウドに送らず手元のモデルで完結させたい」なら、選ぶハードの考え方が変わります。その場合はローカル LLM の必要スペックやコーディング用ローカル LLM の実測比較が出発点になります。

では、同じクラウド型でも Codex で押さえておきたい固有の点は何か。最大の違いは、Codex が手元でコマンドやコードを実行するサンドボックスを持っている点です。ここから先が本題です。

Codex 固有①｜ローカル実行サンドボックスと承認モード

Codex は提案を出すだけでなく、ファイル編集やコマンド実行を手元の環境で行います。その安全装置として、OpenAI 公式は「サンドボックス」と「承認ポリシー」という独立した二層の仕組みを用意しています。サンドボックスが技術的な境界を決め、承認ポリシーがその境界を越える前に確認を挟むかを決める、という分担です。

3 つのサンドボックスモード

公式ドキュメントでは、サンドボックスは次の 3 モードが説明されています。

read-only	ファイルの読み取り・検査に限定する sandbox。on-request と組み合わせた場合、編集・コマンド実行・ネットワークアクセスには承認が必要
workspace-write（信頼済みフォルダの Auto 構成で使用）	作業ディレクトリ内の読み書きと、定型的なローカルコマンドの実行が可能。ネットワークアクセスや境界外の操作は承認待ち
danger-full-access	サンドボックス制限なし。ファイルシステムとネットワークの境界が外れる。信頼できる用途に限定すべきモード

信頼済みのバージョン管理フォルダでは、Auto 構成（workspace-write＋on-request）が標準的に使われます（書き込みは作業ディレクトリ内に制限される一方、読み取りの範囲は比較的広いため、機密ファイルの取り扱いには注意します）。一方、未信頼の作業ディレクトリやバージョン管理されていないフォルダでは、read-only が推奨・初期状態になる場合があります。

標準の Auto 構成では、サンドボックス内で Codex が起動するコマンドやサブプロセスのネットワークアクセスが既定で無効で、外部通信や作業フォルダ外への変更には承認が必要です。ただし無効なのはあくまでサンドボックス内コマンドの通信で、OpenAI モデルとのモデル通信や設定可能な Web 検索機能（既定は cached）は別経路です（「外部送信ゼロ」ではない点に注意。--yolo や full access 設定では Web 検索が live 既定になります）。workspace-write のネットワークは設定（sandbox_workspace_write.network_access）で有効化でき、danger-full-access はこの境界自体を外します。依存パッケージの取得など通信を伴う操作でつまずいたら、まずこのネットワーク既定無効を思い出すと切り分けが早くなります。

サンドボックスの実体は OS ネイティブの仕組みです。Codex 公式によれば、macOS は Seatbelt、Linux は bwrap と seccomp、WSL2 は Linux sandbox 実装、Windows ネイティブ実行時は Windows sandbox 実装を使います。隔離するのはおもにファイルシステム（ワークスペース外への書き込み）とネットワークです。OS によって実装が違うため、同じ設定でも環境によって挙動が変わり得る点は頭に入れておくとよいでしょう。

承認ポリシーは別レイヤー

承認ポリシー（approval policy）はサンドボックスとは別の制御で、コマンド実行や境界越えの前に確認を挟む頻度を --ask-for-approval（短縮は -a）で決めます。公式が挙げる値は次の 3 つです。

untrusted	既知の安全な読み取りコマンドのみ自動実行。状態変更を伴う操作や、信頼済みセットに含まれないコマンドは承認が必要
on-request	対話的に、Codex が必要と判断したときに承認を求める（ローカル作業の標準）
never	承認を求めない非対話モード。CI など無人実行向け

運用は「サンドボックス（できる範囲）×承認ポリシー（止めて聞くタイミング）」の掛け合わせで決まります。公式が示す代表的な組み合わせは次のとおりです。

運用	サンドボックス × 承認	挙動
Auto（信頼済みフォルダで推奨）	workspace-write × on-request	ワークスペース内は自動、外部編集・ネットワークは承認
安全な読み取り	read-only × on-request	読み取りのみ自動、編集・コマンド・通信は承認
CI・無人実行	read-only × never	読み取りのみ・承認なし

codex exec は既定で read-only sandbox で動きますが、ユーザー設定の影響を受けるため、自動化では必要な権限を明示するのが安全です。読み取り専用なら --sandbox read-only、ワークスペース内の編集が必要なら --sandbox workspace-write、広範なアクセスが要る場合は隔離された CI ランナーやコンテナで danger-full-access を指定する、と切り分けます。CI で API キーを使う場合は、OPENAI_API_KEY や codex exec 専用の CODEX_API_KEY をジョブ全体の環境変数に置かず、必要な codex exec 呼び出しだけにスコープするのが安全です（CODEX_API_KEY は codex exec でのみ有効。ビルド・テスト・依存フックや侵害された action が同じ環境変数を読めてしまうため）。旧来の codex exec --full-auto は非推奨の互換経路とされ、公式は codex exec --sandbox workspace-write の利用を案内しています。逆にすべての制限を外す --dangerously-bypass-approvals-and-sandbox（別名 --yolo）はサンドボックスも承認も無効化するため、使うのは信頼できる隔離環境（使い捨てコンテナ等）に限るのが安全です。

サンドボックスと承認を緩めるほど自動化は進みますが、未確認のコマンドが手元で走るリスクも上がります。とくに danger-full-access は文字どおり制限を外すモードなので、信頼できるリポジトリと用途に限るのが無難です。緩める設定は、まず read-only や既定の workspace-write で挙動を把握してから段階的に検討するのが安全です。

Codex 固有②｜Node.js・Git・インストール経路

Codex CLI の導入経路は複数あり、必要な前提も方式で変わります。

もっとも手軽なのは公式のインストーラーです。macOS と Linux は curl でインストールスクリプトを取得して実行する形が案内されています。Windows は PowerShell でインストールスクリプトを実行します。これらは追加のランタイムを前提としない方式です。

一方で npm 経由（npm i -g @openai/codex）でも導入できます。この場合は Node.js が必要です。必要バージョンは配布版で変わり得るため、導入時に公式配布情報（npm の engines 表示）を確認するのが確実です。導入経路はこのほかにも、macOS 向けの Homebrew や、OpenAI 公式 GitHub リポジトリの Releases で配布される事前ビルド済みバイナリ（ランタイム非依存）があります。Node.js を用意したくない場合は、公式インストーラーやバイナリ方式を主に検討するとよいでしょう。

また、対話 CLI の導入自体に Git が必須とは限りませんが、Codex が変更した内容を確認・復元しやすくするため、利用できる状態にしておくと安心です（公式 Quickstart もタスク前後の Git チェックポイント作成を推奨）。なお codex exec の非対話実行では、破壊的変更を防ぐため既定で Git リポジトリ内での実行が求められ、安全性を確認できる場合のみ codex exec --skip-git-repo-check で上書きできます。

クラウドモデル利用	OpenAI サービスへのネットワーク接続が必要。専用 GPU は不要
`--oss` 利用	Ollama や LM Studio などのローカルプロバイダーと、使用モデルに応じたローカル計算資源（GPU/RAM）が必要
公式インストーラー	macOS/Linux はシェルスクリプト、Windows は PowerShell スクリプト。Node.js 不要
npm 方式	Node.js が必要（必要バージョンは利用時点の公式配布情報で確認）。`npm i -g @openai/codex`
その他の導入	macOS は Homebrew、各 OS は公式 GitHub Releases のバイナリ（Node.js 不要）
Git	対話 CLI 導入には必須でないが利用推奨。`codex exec` 非対話は既定で Git リポジトリ内実行が必要（`--skip-git-repo-check` で上書き）

OpenAI モデル利用時の認証は codex login で行う

OpenAI のモデルを利用する場合、認証は codex login で行います。公式によれば、ChatGPT の OAuth サインインのほか、デバイス認証・API キー・アクセストークンに対応します。codex login status で現在の認証状態を確認でき（成功時は終了コード 0 を返す）、codex logout で保存済みの認証情報を消せます。CLI 本体の更新は、インストール済みリリースが self-update に対応している場合、codex update で確認・適用できます。

つまずいたら codex doctor

環境まわりでうまく動かないときに役立つのが codex doctor です。インストール・設定・認証・ランタイム・Git・ターミナルなどをまとめて診断してレポートを出すので、「動かない」ときはまずこれを走らせると、どの層の問題かの当たりが付きます。

個人設定は ~/.codex/config.toml に置かれ、信頼済みプロジェクトではリポジトリ内の .codex/config.toml でプロジェクト単位の設定も行えます。優先順位は、CLI 引数・--config 上書き → プロジェクト設定 → プロファイル → ユーザー設定 → システム設定 → 組み込み既定値の順です。よく使う組み合わせ（例: --sandbox workspace-write --ask-for-approval on-request）はプロファイル化して --profile で呼び出せます。なお Business／Enterprise などの組織管理環境では、管理者が強制する設定が優先される場合があります。

Windows で動かすときの注意点

Codex CLI は Windows でネイティブ実行でき、必要に応じて WSL2 でも利用できます。公式は、Windows ネイティブ実行では Windows sandbox を使い、Linux ネイティブな環境が必要な場合などには WSL2 を選択肢として案内しています。

OpenAI 公式は、Windows ではネイティブの Windows サンドボックスを既定の選択肢として推奨しており、推奨の elevated sandbox とフォールバックの unelevated があります。推奨環境は Windows 11 で、完全更新済みの Windows 10 は best effort 扱いです。WSL2 は、Linux ネイティブなツールチェーンが必要な場合や、ネイティブ sandbox が用途に合わない場合の選択肢という位置づけです。

注意点として、2026 年 6 月 3 日時点で、OpenAI 公式リポジトリには、Windows 上の Codex Automations で danger-full-access を指定しても read-only 相当になる、というユーザーからの未解決 Issue 報告があります（その際、Windows sandbox の DangerFullAccess 関連エラーが示されます）。これは公式に確定した仕様説明ではなく、Automations に関する個別報告として扱うべきで、Windows ネイティブ CLI 全般で full access が使えないことを意味するものではありません。フルアクセス相当が必要でネイティブ sandbox が合わない場合は、WSL2 を検討するとよいでしょう。

権限まわりやサンドボックスの初期化でつまずいたときは、(1) 既定の workspace-write のままで再現するか、(2) Windows ネイティブ実行と WSL2 で挙動が変わるか、(3) 承認ポリシーを過度に緩めていないか、の順で切り分けると原因に近づきやすいです。Windows はネイティブ実行と WSL2 でサンドボックス実装が異なるため、どちらで動かしているかを最初に確認するのが近道になります。

「とりあえず安全側で試したい」なら、Windows でもまずは既定（Auto＝workspace-write・ネットワーク無効・承認あり）で動かし、必要に応じて承認ポリシーだけ緩めるのが扱いやすい入り方です。Linux ネイティブのツールチェーンが必要な場合や、ネイティブ sandbox が用途・組織ポリシーに合わない場合は、WSL2 を選択肢として検討すると整理しやすいでしょう。

ChatGPT アカウントと API キー｜認証と料金

OpenAI のモデルを Codex CLI で利用するには認証が必要です。通常の認証方式は次の 2 つです（このほか、Enterprise の信頼済み自動化向けに、アクセストークンを渡す codex login --with-access-token も用意されています）。

ひとつは ChatGPT アカウントでのサインイン。2026 年 6 月時点の OpenAI の現行案内では、Codex は Free / Go / Plus / Pro / Business / Edu / Enterprise の各 ChatGPT プランに含まれます。対象プランや利用上限は変更され得るため、利用開始時に公式案内を確認してください。ChatGPT アカウントでサインインすればそのまま使い始められ、利用は各プランの利用上限・クレジット体系に従います。もうひとつは OpenAI の API キーでのサインインです。API キー認証ではローカルの Codex ワークフローは使えますが、ChatGPT ワークスペースやクラウドサービスに依存する一部機能は制限・利用不可になり、料金は ChatGPT プラン枠ではなく標準の API 料金が適用されます。まず手軽に始めるなら ChatGPT アカウントでのサインインが扱いやすいでしょう。なお、機密コードを扱う場合は利用プランのデータコントロールも確認しておくと安心です。OpenAI の案内では、Business・Enterprise・Edu と API は既定で入力・出力をモデル改善に使わない一方、Free・Go・Plus・Pro などの個人向け ChatGPT 利用では、設定でオフにしない限り Codex で処理した内容がモデル改善に使われ得るとされています。また Codex の full environments には別個のトレーニング許可設定があり、ChatGPT 画面や privacy portal の変更がそちらに及ばない場合があるため、Codex Settings 側の設定も確認してください。

OpenAI のモデルを使う場合、推論はクラウド側で行われ、CLI から利用モデルを選択・切り替えできます。既定モデルや対応モデルは提供状況により変わり得るため、最新情報は公式ドキュメントで確認するのが確実です。なお --oss でローカルモデルを利用する場合は推論が手元で行われ、必要なハードウェア要件が変わります。

つまり OpenAI のクラウドモデルを使う通常運用で用意すべきなのは、高性能 GPU よりも「ChatGPT アカウントまたは API キー」と「サンドボックス・承認・OS まわりを理解した実行環境」です。--oss でローカルモデルを使う場合は、これに加えてローカル推論用の計算資源が論点になります。

Claude Code とのスペック観点・早見表

同じクラウド型でも、環境設計の力点は少し違います。マシン選びの基本はおおむね近いので、下表は「どこが似ていて、どこが Codex 固有か」を整理したものです。なお Claude Code 側の要件は、Anthropic 公式のセットアップ情報と別記事（Claude Code 推奨スペック）の確認に基づきます。最新仕様は各公式案内をご確認ください。

観点	Codex CLI	Claude Code
処理の場所	モデル推論は OpenAI クラウド（`--oss` 時はローカル）／編集・実行はローカル	モデル推論はクラウド（Anthropic API 等）／編集・実行はローカル
ローカル GPU	OpenAI モデル利用時は不要／`--oss` は利用モデル次第	不要
効くハード	RAM・SSD・回線（共通）	RAM・SSD・回線（共通）
ローカル実行	サンドボックス（3 モード・Auto は workspace-write＋on-request）が中心	権限設定あり（GPU 不要の基本は別記事）
Windows	ネイティブ sandbox（公式既定推奨・Win11）か WSL2	Windows 対応あり（方式・前提は公式／別記事で確認）
認証	ChatGPT アカウント／API キー	Claude.ai／Console アカウント（構成により Amazon Bedrock・Google Vertex AI 等）

マシンそのものの選び方（予算帯・ノート PC の見極め）の観点は両者でおおむね近いので、その部分はClaude Code 推奨スペックの記事を入口として使うのがおすすめです。本記事の Codex 固有の話（サンドボックス・Windows・Node.js・認証）と合わせて読むと、両ツールの環境像がそろいます。

まとめ

Codex CLI の「推奨スペック」を一言でまとめると、OpenAI のクラウドモデルを使う通常運用では高性能 GPU は要らず、効いてくるのは RAM・SSD・回線という、Claude Code ともおおむね共通する基本に行き着きます。マシン選びそのものはその共通項で足ります（ローカルモデルを使う --oss は別途ハード要件を要検討）。

そのうえで Codex に固有なのは、ハードではなく実行環境の設計です。手元でコードを動かすサンドボックス（信頼済みフォルダの Auto＝workspace-write・ネットワーク既定遮断）と承認ポリシーの二層、インストール方式ごとの前提環境（npm 利用時の Node.js など）や Git、そして Windows ではネイティブ sandbox と WSL2 で実行環境が変わる点。この 3 つを押さえておけば、導入時のつまずきはかなり減らせます。まずは既定の安全側で動かし、必要に応じて承認だけ緩める——という入り方を出発点にしてください。

よくある質問（FAQ）

Q. Codex CLI に GPU は必要ですか？

OpenAI のクラウドモデルを使う通常運用では不要です。推論はクラウドで行われ、手元のマシンは指示送信とコード編集・実行を担うだけなので、ローカル GPU や VRAM は要りません。効いてくるのは RAM・SSD・回線です。なお Codex CLI には --oss でローカルモデルプロバイダー（公式では Ollama や LM Studio が例示）を使う選択肢もあり、その場合は使用するモデルに応じて GPU・RAM などの計算資源が要点になります（CPU 実行や量子化モデルなど構成により必要量は変わります）。

Q. Claude Code とスペック要件は違いますか？

マシン選びの基本（クラウドモデル利用時は GPU 不要で、RAM・SSD・回線が効く）はおおむね近いと考えてよいでしょう。違いは Codex がローカル実行サンドボックスと承認ポリシーを持つ点、Windows でネイティブ sandbox と WSL2 を選ぶ点、Node.js などの導入前提です。基本の PC 選びは Claude Code 推奨スペックの記事が入口になります。

Q. Windows ネイティブでも問題なく動きますか？

Windows ネイティブで利用できます。公式の推奨環境は Windows 11 で、ネイティブ sandbox には推奨の elevated とフォールバックの unelevated があります。ただし管理された端末では、ローカルユーザー作成・ファイアウォール・ログオン権限などのポリシーでセットアップが失敗する場合があります。WSL2 は Linux 向けツールチェーンが必要な場合や、ネイティブ sandbox が用途に合わない場合の選択肢です。なお、Windows 上の Automations で full access 設定が read-only 相当になるという未解決の Issue 報告（ユーザー報告）もあります。

Q. Node.js は必須ですか？どのバージョンですか？

インストーラー・Homebrew・バイナリ方式なら Node.js は前提になりません。npm 方式（npm i -g @openai/codex）では Node.js が必要です。必要バージョンは配布版で変わり得るため、導入時に公式配布情報（npm の engines 表示）を確認してください。

Q. 使うのに ChatGPT の有料プランは要りますか？

2026 年 6 月時点の OpenAI の現行案内では、Codex は Free / Go / Plus / Pro / Business / Edu / Enterprise の各 ChatGPT プランに含まれます。ただし利用上限はプランごとに異なり、上限到達時の選択肢もプランやワークスペース権限によって変わります。対象プランや上限は変更され得るため、利用開始時に公式案内を確認してください。API キーでも使えますが、標準の API 料金が適用され、ChatGPT ワークスペースやクラウドサービスに依存する一部機能は制限されます。