Codex CLIの使い方｜Windows・macOSの導入手順

01Codex CLIを選ぶ条件と、最初に決める4点

Codex CLIは、ターミナルからローカルのコードを読み、編集し、コマンドを実行できるOpenAIのクライアントです。Codexという製品、CLIという利用する入口、GPTというモデル、ChatGPT／APIという請求経路は別々に選びます。ソースコードはOpenAIの公式GitHubで公開されています。

手元のリポジトリとシェルを行き来する人にはCLIが合います。端末操作を避けたいならデスクトップアプリ、エディター内で進めたいならIDE拡張も比較してください。以下の第一候補は公式の順位ではなく、初回の切り分けを簡単にするための筆者の判断基準です。

インストールできること、ログインできること、希望するモデルやCLIを利用できることは同じではありません。対象のプランと組織設定を確認してから、導入へ進みます。

根拠：CLIの役割・導入、認証方式、料金・提供範囲

02Windows・macOS・WSL2の導入手順

Windowsではネイティブ環境が使えます。Linux固有ツールが必要、すでにWSL2内で開発している、利用できるWindowsサンドボックスが要件に合わない場合にWSL2を検討します。WSL2を選んだら、導入・認証・作業フォルダをLinux側にそろえてください。

公式は更新済みWindows 10をベストエフォートとし、実用上1809以降が必要としています。ただし、この下限は新しいサンドボックスMXCの対応条件ではありません。MXCは対応するWindows 11端末が必要で、CLI側の設定と組織ポリシーも関わります。管理対象PCでは管理者指定の方式を使い、セキュリティ設定を独断で弱めません。WSL1はCodex 0.114までの対応で、0.115以降は対象外です。

根拠：Windowsとサンドボックス、WSL2の条件

1．使う導入経路を1つ選ぶ

スタンドアロン版ならnpmを前提にしません。npm経由ではNode.jsとnpmが必要です。以下は公式掲載のコマンドです。ダウンロードしたスクリプトを実行するため、配布元と内容を理解し、組織の許可を確認してから使ってください。本記事では実行していません。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

上のWindows例にはそのプロセスのExecutionPolicy指定が含まれます。組織ポリシーを迂回する許可ではありません。実行が制限される場合は止めて管理者に確認し、恒久的なポリシー変更を自己判断で追加しないでください。

npm install -g @openai/codex

brew install --cask codex

2．起動する環境でバージョンを確認する

codex --version

認識されなければターミナルを開き直し、WindowsとWSL2のどちらに入れたか、PATHが一致するかを確認します。別方式を重ねて入れる前に、既存の導入先を調べます。更新は同じ経路で行い、Homebrewは brew upgrade --cask codex、スタンドアロンとnpmは上記と同じコマンドが公式例です。バージョンの最新値や最低Node.js・macOSの数値はここでは固定しません。

根拠：インストール・更新コマンド

03ChatGPTとAPIキーの認証・料金・モデルを分ける

ChatGPTログインでは対象契約の利用枠を使い、APIキーではOpenAI PlatformのAPI料金で課金されます。ChatGPTの月額契約があるからAPI利用もその枠内、とは判断しないでください。認証方式は管理者の制御やデータの扱いにも影響します。

2026年10月23日（日本時間）に確認した公式料金表では、PlusにCLIアクセスが明記されています。一方、Free／Goの具体的な案内はデスクトップアプリのGPT-6 Luna・Standard速度で、段階提供の条件付きです。「Codexを含む」という総論だけで無料アカウントからCLIも必ず使えるとは言えません。組織契約では席・ロール・管理者設定も確認します。

根拠：プランごとの利用面、請求と認証の関係

ブラウザでログインし、認証状態を確認する

codex login

codex login status

ブラウザを開けないリモート端末などでは、アカウントまたは管理者側で許可したdevice code認証（beta）を使える場合があります。codex login --device-auth はChatGPT認証の別経路で、APIキー認証への切り替えではありません。保存済みの認証を解除する場合は codex logout を使います。組織が用意したworkload identityなど、実行環境で認証が管理される場合は別の手順になります。

APIキーを使う場合、公式は環境変数から標準入力に渡す例を案内しています。以下はその環境変数が安全に設定済みのmacOS／Linux系シェル向けです。キーの値をコード、履歴、チャット、共有ログに貼り付けないでください。PowerShellにそのまま転用せず、利用するシェルの手順を確認します。

printenv OPENAI_API_KEY | codex login --with-api-key

認証情報は ~/.codex/auth.json またはOSの資格情報ストアなどに保存されます。auth.jsonはトークンを含み得るため、パスワードと同様に扱い、問い合わせへの添付やGit登録を避けます。API利用料はOpenAI API料金で確認してください。Enterpriseには管理されたアクセス・トークンによる自動化もありますが、初回導入とは分けて管理者の手順に従います。

根拠：認証・device code・保存先

モデルはログイン後の表示を優先する

対話中の /model で利用可能なモデルと推論の強さを確認します。現行公式にはGPT-6.1 Sol、GPT-6 Sol、GPT-6 Lunaなどが掲載され、契約・利用面・段階提供で候補が異なります。モデル名はプラン名でも安全性の順位でもありません。初回は利用可能な既定設定から始め、複雑さ・速度・費用を見て調整します。

旧版で扱った8月31日の情報は、未来の予定ではなく退役済みの記録として残しています。自動化は画面のモデル選択だけでなく、保存設定・スクリプト・組織設定に残るモデル指定も点検します。

根拠：現行モデル・退役の対象範囲

04初回はread-onlyで調べ、小さな編集へ切り替える

「Ask for approvalなら、編集のたびに必ず止まる」という理解は誤りです。 サンドボックスは読み書きや通信の技術的な範囲、承認方針はその範囲を超える操作をいつ誰が審査するかを決めます。workspace-writeとon-requestの組合せでは、許可範囲の読み取り・編集・コマンド実行は自動で進められます。

Ask for approvalとApprove for meは審査先の違いも含みます。後者が使える場合でも、選択しただけでサンドボックスが広がるわけではありません。実際の設定は /permissions で確認し、モード名だけで安全性を判断しません。

根拠：Permissionsの2つの制御、read-onlyとworkspace-write

1．既存作業を保全し、対象フォルダだけを開く

まず自分のターミナルで対象プロジェクトへ移動します。以下はGit管理済みリポジトリでの事前確認例です。Git未導入・未管理の場合は、編集対象を別の場所にバックアップして復元できることを確認します。

git status --short
git diff --stat
git diff
git diff --cached

未コミットの変更が誰の作業か、未追跡ファイルがないかを確認します。通常のgit diffだけでは未追跡ファイルの内容は見えません。既存作業を確認せず一括コミット・削除・リセットしないでください。ブランチを作るだけでは未コミットやGit管理外のデータのバックアップにはなりません。編集前のチェックポイントと、必要なファイルの別バックアップを用意します。

2．読取専用を指定して起動する

codex --sandbox read-only --ask-for-approval on-request

起動後は /permissions で有効な範囲を確認します。以下は筆者作成の依頼例です。「編集しない」という文章だけで技術的制限を代用せず、read-onlyと併用します。

このプロジェクトを調査してください。ファイルの編集・作成・削除はしないでください。
READMEと関連する設定から、目的、主要ファイル、実行方法、既存のテストを整理してください。
秘密情報の値は表示しないでください。確認したファイルと未確認点を区別してください。
インストール、テスト、外部通信、権限拡張が必要なら実行せず、理由と必要範囲を説明してください。

read-onlyは「何も実行しない」「ネットへ何も送らない」という意味ではありません。許可された調査コマンドは動きます。範囲外の承認を求められても、調査だけのつもりなら承認せず、何のための変更かを確認してください。

3．対象とテストを決めてから編集権限に切り替える

説明に問題がなければ、修正するファイル、触らない範囲、成功条件を決めます。/permissions で変更可能な範囲を選ぶか、現在のセッションを終了して次のように新しい対話を始めます。新規起動では前の説明を自動で引き継ぐと考えず、必要な文脈を依頼に添えます。

codex --sandbox workspace-write --ask-for-approval on-request

READMEのセットアップ説明だけを修正してください。
調査で確認した現行の実行方法に合わせ、既存のコード・依存関係・認証設定は変更しないでください。
既存の未コミット変更を上書きしないでください。
追加インストール、外部通信、対象外の編集が必要なら、その理由を先に示してください。
最後に、変更ファイル、変更理由、確認した項目、未確認項目を報告してください。

ネットワークは標準のworkspace-writeでは既定で無効ですが、設定や組織方針で変わります。これはコマンド側の通信制約です。モデルとの通信や、別の権限で動くWeb検索・MCP等まで完全オフラインになるとは限りません。通信が必要なときは宛先と送る情報を確認し、エラーを消すためだけにfull accessを選ばないでください。

4．差分・テスト・未追跡ファイルを確認して採用する

完了報告だけで終えず、/diff とGitの状態を確認します。変更した行だけでなく削除・新規ファイルも見て、既存作業との差分を区別します。テストはプロジェクトで定めたものを選び、ファイル作成・外部サービス・費用が生じるものは実行前に確認します。

依頼と無関係な変更があれば、そのまま全体を採用しません。人の作業を含む可能性があるので一括破棄もしません。確認済みの変更だけを取り込み、必要なGitチェックポイントを残します。/review は追加レビューに役立ちますが、結果が空でも不具合がない保証にはなりません。

根拠：Gitチェックポイント、サンドボックス・ネットワークの範囲、差分・レビュー・権限操作

05基本コマンドと、止まったときの確認順

シェルで入力する codex ... と、起動中の入力欄で使う /... を区別します。すべてを暗記せず、状態・権限・差分・終了から覚えれば十分です。

根拠：CLIのコマンド一覧

エラーは発生した層だけを調べる

この順番は筆者の切り分け例であり、各エラーを必ず直す公式の万能手順ではありません。広い障害が疑われるときは先にOpenAI Statusを確認して構いません。障害が掲載されていないことも、端末側に原因がある証明にはなりません。

解決しなければ、OS・シェル・導入経路・CLIバージョン・認証方式・エラーが出た操作を記録して管理者やサポートへ伝えます。ログからキー、トークン、個人情報、非公開コードを除きます。認証だけで止まる場合は認証方式別のログイン確認ガイドへ進んでください。

根拠：導入、認証、Windowsの制約

06導入前によくある質問

根拠：読取専用と承認、導入方式

データ・権利の根拠：モデル改善へのデータ利用、Business data、個人向け利用規約。法人・APIでは適用される法人契約も確認してください。