OpenAI Codex CLI のインストール方法(Windows・macOS・Linux)
Codex CLI は約5分でインストールできます。macOS/Linux ではコマンド1つ、Windows では PowerShell コマンド1つで完了し、インストールスクリプトか Homebrew を使えば Node.js は不要です。本ガイドでは3つの OS すべての実際のコマンド(Windows では実機で検証済み)、config.toml のリファレンス表、エラー対処表、そして FAQ を紹介します。
- コマンドとドキュメントのパスは、執筆時点(2026年8月)の公式ドキュメントと照合しています。Codex のドキュメントドメインはすでに一度移転しており(developers.openai.com → learn.chatgpt.com)、このページが古い場合は実行前に最新の公式ドキュメントを確認してください。
Codex CLI をインストールする前に
OpenAI Codex をインストールする前に、次のものをそろえておきましょう。
- Codex に対応した ChatGPT プラン。 執筆時点の料金ページによると、CLI へのアクセスは Plus 以上(Plus、Pro、Business、Enterprise)、または API キーによる従量課金が最も確実です。Free/Go には含まれない場合があるため、当てずっぽうにせず、インストール前に Codex の料金を確認してください。
- OS: Windows、macOS、Linux のいずれか。Codex CLI は3つすべてでネイティブに動作し、Windows でも WSL2 は不要で、Apple Silicon と Intel で別々のビルドを考える必要もありません(インストーラーが適切なバイナリを選んでくれます)。
- chatgpt.com への正常な接続。 インストーラーの取得とサインインに必要です。ほかのインターネットは問題なく使えても、社内のキャプティブプロキシや制限の厳しいネットワークではダウンロードがブロックされることがあります。
- Node.js は npm インストールを選んだ場合のみ必要です。ほかの2つの方法(インストールスクリプト、Homebrew)は Node を一切使いません。
この4つをそろえれば、実際のインストールはコマンド1つと短いダウンロード待ちだけです。通常より時間がかかりがちなのは、サインインに使う正しい ChatGPT アカウントを選ぶ部分で、特に個人アカウントと会社支給のアカウント(Business/ワークスペース)の両方を持っている場合はそうです。この2つは異なる CLI 権限を持つことがあるため、サインイン画面に見覚えがなかったり、CLI が予想外のプランを表示したりする場合は、何かが壊れていると決めつける前に、実際にどのアカウントで認証されているかを確認してください。
macOS と Linux に Codex CLI をインストールする
最速の方法は 公式インストールスクリプトで、ターミナルで直接実行します。ネイティブバイナリを取得するだけで、ほかのランタイムは必要ありません。
curl -fsSL https://chatgpt.com/codex/install.sh | sh
curl の出力をそのまま sh にパイプすることに抵抗を感じる人もいますが、その感覚は一般的には妥当です。その瞬間に URL が返す内容を信頼することになるからです。中身を読まずにスクリプトを実行したくない場合は、まずダウンロードして(curl -fsSL https://chatgpt.com/codex/install.sh -o install.sh)中身を読んでから sh install.sh を実行してください。よく知られたベンダーの公式ドメインで一度きりのインストールなら、たいていの開発者はこのリスクを受け入れます。制限の厳しい環境や共有マシンでは、ダウンロードしてから読むというひと手間をかける価値があります。
パッケージマネージャーで管理したい場合は、次の2つの代替手段があります。
brew install --cask codex
npm install -g @openai/codex
最もよくある落とし穴: npm パッケージ名は単なる codex ではなく @openai/codex です。npm install -g codex を実行すると、別のパッケージがインストールされる(または 404 になる)ことがあります。私が読んだ英語ガイドのうち2つが、まさにこの間違いを指摘しています。npm を使う場合は、最新の Node.js LTS リリースを使ってください。照合した二次情報源では最小バージョンについて意見が一致していないため、npm がバージョンエラーを出したら、まず Node を最新の LTS に更新するか、上記のインストールスクリプトか Homebrew で問題そのものを回避してください。念のため確認したい場合は GitHub の公式 README を参照してください。
どれを選ぶべきでしょうか。一度きりのインストールで手動更新を気にしないなら、インストールスクリプトが最速です。ほかのすべての CLI をすでに Homebrew で管理しているなら、その習慣を続けましょう(あとで brew upgrade すれば Codex も更新されます)。npm の方法は、ほかの用途ですでに Node.js をインストールしている場合にのみ意味があります。この方法のためだけに Node をインストールするのはやめましょう。
Windows に Codex CLI をインストールする
Windows では PowerShell を開き、次のコマンドをそのまま実行します。私はこの記事を書きながら自分の Windows マシンで実際に実行しました。
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
- PowerShell を開きます(ほとんどのマシンで管理者権限は不要です)。
- 上記のコマンド全体を貼り付けて Enter を押します。
-ExecutionPolicy ByPassフラグはこの1回の実行にのみ適用され、マシンのポリシーは変更しません。署名されていないこのインストールスクリプトを、この一度だけ実行できるようにするだけです。- 古いターミナルを閉じて新しいものを開き、更新された PATH を反映させます。
codex --versionを実行して確認します。
Windows Terminal がインストールされているなら、従来の cmd.exe ウィンドウより Windows Terminal をおすすめします。必須ではありませんが、PowerShell のプロンプトや Codex が出力するカラー表示がより確実に表示され、上記の実機検証でも私はこれを使いました。
Codex CLI は Windows でネイティブに動作し、WSL2 は不要です。チームがすでに WSL2 を標準にしている場合(たとえば Linux の CI パイプラインとスクリプトを共有するため)は、上の macOS/Linux セクションと同じ curl コマンドを使って WSL2 内に Codex をインストールすることもできます。Windows 専用の WSL2 コマンドは別途ありません。
Windows マシンが会社管理下にある(グループポリシー配下のデバイス)場合、-ExecutionPolicy ByPass はユーザー層だけでなく組織のポリシー層でもブロックされることがあります。その場合は IT 部門に緩和してもらう必要があり、ユーザー側の回避策はありません。また、初めてダウンロードしたばかりのインストーラーを実行するとき、Windows Defender SmartScreen が確認を求めてくることがあります。これは新しいファイルに対する通常の警告であり、何かが壊れている兆候ではありません。
インストールを確認する
codex --version を実行します。バージョン番号が表示されれば完了です。ターミナルが codex は認識されないと表示する場合、ほとんどは PATH が古いままです。ほかを疑う前に、まずターミナル(IDE 内蔵のものも含む)を完全に閉じて、新しいウィンドウを開いてください。複数のインストール方法を試した場合(たとえば npm のあとにインストールスクリプト)で、codex --version が予想外のバージョンを表示するなら、PATH 上に2つのコピーがある可能性が高いです。where codex(Windows)または which codex(macOS/Linux)で実際にどちらが実行されているかを確認し、余分なほうを削除してください。
Codex にサインインする
ターミナルで codex を実行して CLI を起動し、プロンプトが表示されたら ChatGPT でのサインインオプションを選びます(画面上の正確な文言はリリースによって変わることがあるので、その時点で CLI が表示する内容に従ってください)。通常はブラウザのタブが開いてサインインを確認し、その後セッションが自動的にターミナルに戻ります。手動でのトークン貼り付けは不要です。利用できるモデルと使用制限は ChatGPT プランによって決まります。具体的な数値をここで推測するのではなく、プラン別 Codex 料金を参照してください。サインインが無言で失敗する(ブラウザタブは閉じるのにターミナルが確認しない)場合、最もよくある原因は社内の SSO やプロキシ層がリダイレクトを横取りしていることです。CLI 自体が壊れていると決めつける前に、制限のないネットワークで再試行してください。
最初の Codex コマンドを実行する
実際のプロジェクトフォルダに cd してから(空のフォルダではなく—Codex には読んで扱う実際のコードが必要です)、次を実行します。
codex
具体的なことを試してみましょう。たとえば「README を読んで、このリポジトリでテストを実行する方法を3つ挙げて。」。あるいは肩慣らしにもう少し小さなこと:「このリポジトリで行数が最も多いファイルを5つ挙げて。」。Codex がコマンドを実行したりファイルを編集したりする必要がある場合は、まず一時停止して承認を求め(approval_policy の設定によります)、実行しようとする正確なコマンドや差分を表示するので、承認するか却下できます。これはエラーではなく通常の承認フローです。なぜ止まるのか、そしてそれを緩めたり厳しくしたりする方法は、下の設定セクションで説明します。最初の実行がうまくいくと、通常 Codex は読んだ内容や変更した内容の短い要約と、次のステップの提案を表示して終わります。逆に、何もしないうちに即座にエラーが出る場合は、ほぼ間違いなくこのステップではなく上のサインインステップに原因があります。
~/.codex/config.toml の基礎
ユーザー設定は ~/.codex/config.toml にあり、プロジェクトはリポジトリのルートにある .codex/config.toml で上書きできます。優先順位(高い順、公式の設定ドキュメントによる)は次のとおりです。CLI フラグ > プロジェクトの .codex/config.toml > プロファイル(--profile)> ユーザーの ~/.codex/config.toml。 実際にはこういうことです。個人の ~/.codex/config.toml が妥当なグローバルデフォルトとして approval_policy = "on-request" を設定していても、特定のリポジトリの .codex/config.toml がより厳格なワークフローのために approval_policy = "untrusted" を設定していれば、そのリポジトリ内で作業しているあいだはプロジェクトファイルが優先されます。そして一度きりの --approval-policy CLI フラグは、その1回の実行に限り両方に勝ちます。
| キー | 目的 | 例 |
|---|---|---|
model | CLI のデフォルトモデル | model = "gpt-5.6" |
sandbox_mode | エージェントのファイルシステム/ネットワークへのアクセスレベル | sandbox_mode = "workspace-write" |
approval_policy | Codex が一時停止して承認を求めるタイミング | approval_policy = "on-request" |
この3つは、まず調整する価値のあるものです。model は品質・速度・コストのトレードオフを決め、sandbox_mode は Codex が実際に何に触れられるかを決め(より安全な read-only オプションや、デフォルトで実行すべきでない danger-full-access オプションもあります)、approval_policy はどのくらいの頻度で手動承認が必要かを決めます。この3つをすべて1つの ~/.codex/config.toml に入れると、次のようになります。
model = "gpt-5.6"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
これは基本のレイヤーにすぎません。次のレイヤー—Codex にプロジェクト独自の慣習(テスト/ビルドのコマンド、壊してはいけないルール)を教えること—は Codex 向け AGENTS.md にあります。
よくあるインストールエラーと対処法
ほとんどのインストール問題は、次の4つのいずれかに行き着きます。パッケージ名のタイプミス、古い PATH、Windows のデフォルトのスクリプトポリシー、そして Codex がきれいに権限を解決できないフォルダです。以下に、それぞれについて「再インストールして祈る」的な一般論ではなく、実際の対処法を示します。
| エラー | 原因 | 対処法 |
|---|---|---|
| npm の 404、または誤ったパッケージがインストールされる | 正しいパッケージ名ではなく npm install -g codex を実行した | npm install -g @openai/codex を使う |
codex が認識されない / コマンドが見つからない | インストールディレクトリが現在のターミナルセッションの PATH に入っていない | ターミナルを完全に閉じて開き直し、codex --version で再確認する |
| PowerShell が実行ポリシーエラーでスクリプトをブロックする | Windows はデフォルトで署名されていないインストールスクリプトをブロックする | 上のインストールコマンドにある -ExecutionPolicy ByPass フラグをそのまま使う。これはその1回の実行にのみ適用される |
| Windows のフォルダでサンドボックス/書き込み権限の警告が出る | プロジェクトが、Codex が書き込み権限をきれいに解決できないフォルダ(たとえば OneDrive 同期フォルダ)にある | プロジェクトを通常のローカルフォルダ(たとえば C:\Users\<you>\projects の下)に移動する |
注意:似て非なる2つの「curl ... | sh」インストールコマンド
あとで curl -fsSL https://agentkit.best/install.sh | sh という手順に出くわしても、それはまったく別のツールです—AgentKit(ak CLI)で、Codex や Claude Code の上にインストールする有料キットであり、Codex 自体の一部ではありません。2つのコマンドはほぼ同じ見た目(同じ curl -fsSL <domain>/install.sh | sh の形)なので、どちらかをメモやシェル履歴に保存して後で使うなら、ドメインでラベルを付けてください。片方のスクリプトをもう片方だと思ってコピペしないように。
早めに身につけておきたい習慣がもう1つあります。Codex CLI は頻繁にリリースされ、インストールドメインも一部の CLI フラグも、リリース以来すでに一度変わっています。ときどきインストールコマンド(または使った方法の更新手順)を再実行しておくのは、知らないうちに古いビルドを使い続けないための安い保険です。
よくある質問
Codex CLI のインストールは無料ですか?
CLI 自体はオープンソースで無料でインストールでき、バイナリの有効期限が切れたりしつこく催促したりすることもありません。サインインして実際に使うには、Codex に対応した ChatGPT プラン(執筆時点の料金ページによると Plus 以上が最も確実)か、従量課金の API キーが必要です。
API キーは必要ですか?
Codex に対応した ChatGPT プランでサインインするなら不要です。それが個人開発者の多くにとってのデフォルトの方法です。API キーが必要なのは、ChatGPT プランを使う代わりにトークン単位で支払いたい場合だけです(対話的なサインインが現実的でない自動化/CI で役立ちます)。
Node.js なしでインストールできますか?
できます。公式インストールスクリプト(macOS/Linux では curl ... | sh、Windows では PowerShell)と Homebrew は Node.js をまったく必要としません。Node が必要なのは npm install -g @openai/codex の方法だけで、npm 自体が Node.js に付属しているためです。
Windows で WSL は必要ですか?
いいえ。Codex CLI は独自のインストーラーと独自のバイナリで Windows 上でネイティブに動作します。WSL2 が役立つのは、既存の Linux パイプラインやシェルスクリプトをチームで共有したい場合に限られます。
更新はどうやりますか?
最初に使ったのと同じインストール方法(インストールスクリプト、brew upgrade、または npm install -g @openai/codex)を再実行すれば、古いバージョンが最新版で上書きされます。先に別途アンインストールする手順は必要ありません。
Codex をインストールしたあとに AgentKit を追加する?
Codex CLI 自体は無料です(すでに持っている ChatGPT プランに乗っかります)。AgentKit は、自分で組み立てる代わりに、あらかじめ用意された skill/subagent/ワークフローを手に入れるために Codex の上にインストールする、別個の有料レイヤーです:ak kit init engineer --target codex --global を実行し、プレビュー画面を確認し、新しい Codex セッションを開いて、$ak:cook ... を実行して始めます。これによって、いま入れたばかりのベースの codex コマンドが変わることは何もありません—そのコマンドに対して実行できる、より構造化されたものを与えるだけです。これは使い捨ての宣伝ではなく、私が実際に Claude Code と Codex の両方で回しているのと同じゲート設定です—その仕組みは AgentKit in Codex で解説しています。今日はまず Codex を軽く試すだけなら、このステップは丸ごと飛ばして、毎セッション自分のワークフローを説明し直す手間を実際に感じるようになってから戻ってきてください。そこが、あらかじめ用意されたキットが元を取り始めるポイントです。
ワークフローを自分で組み立てる代わりに、あらかじめ用意されたものが欲しいですか? AgentKit Engineer Kit は、ベース CLI の使い方を変えることなく、ak kit init で Codex(および Claude Code)に直接インストールできます。