Codex CLI Linuxの導入と使い方

Codex CLI Linuxとは何か

Codex CLI Linux版は、Linuxの端末から開発用リポジトリを開き、ファイルを読み、依頼に応じて変更案を作り、必要な検査を実行するためのCodexです。ブラウザーで使うCodex Webやデスクトップアプリとは入口が違い、作業対象のディレクトリと端末の状態を手元で確認しながら進められる点に特徴があります。OpenAIの公式READMEも、Codex CLIをコンピューター上で動くコーディングエージェントと説明しています。出典: https://github.com/openai/codex/blob/main/README.md

モデルを選ぶサービスの話と、Linuxでコマンドを受け付けるクライアントの話は分けて考える必要があります。Linux側に入るのはCodex CLI本体であり、リポジトリのパス、シェル、ファイル権限、ネットワーク接続は端末側の条件です。ChatGPTでサインインする場合でも、どのフォルダーを開いているか、差分を誰が確認するかは利用者が決めます。したがって、導入が終わったことと、安心して作業を任せられることは同じではありません。

Linuxで使う前に理解したい三つの層

第一の層は端末とリポジトリです。Codexが読むファイル、書き込める場所、利用できるコマンドはLinux側で決まります。第二の層はモデルとサインインです。同じCLIでも、選んだモデルや契約条件によって応答の速さ、利用できる範囲、得意な作業が変わります。第三の層は確認の手順です。提案された差分、検査結果、エラーの内容を人が見てから取り込む、という境界を先に決めておくと、導入直後の試行でも作業を戻しやすくなります。

2026年10月にLinux利用者が確認したい更新

2026年10月3日時点で、Codex CLIの安定版としてまず確認する対象は0.160.0です。OpenAIの公式GitHubリリースでは、0.160.0が10月1日に公開された最新版として表示され、Linux X11端末での選択範囲の貼り付けや、古い作業を一覧から追加表示する操作が記載されています。Linuxで使う人に直接関係する改善と、全利用者向けのセッション整理が同じリリースに含まれているため、版番号だけでなく変更内容も見ておく価値があります。出典: https://github.com/openai/codex/releases/tag/rust-v0.160.0

公式リリース一覧には、10月2日に0.162.0-alpha系も並んでいます。新しい機能を早く試したい場合には候補になりますが、設定や表示が変わる可能性があるため、普段の作業で使う安定版と同じ場所に混在させないほうが判断しやすいでしょう。最新という言葉だけで試験版へ移るのではなく、まず安定版で導入経路と検査の基準を固めることが、Linux環境では特に重要です。出典: https://github.com/openai/codex/releases

0.160.0安定版で押さえるポイント

0.160.0のリリースノートには、ローカルLinuxのX11端末で選択した文字を中クリックで貼り付ける対応、作業一覧で古いタスクを追加表示する操作、プロジェクト外から始めるセッションの扱いなどが記載されています。端末の種類によって利用できる操作は異なるため、機能名だけでなく、自分がX11かWaylandか、フルスクリーンの端末画面を使っているかも確認します。出典: https://github.com/openai/codex/releases/tag/rust-v0.160.0

alpha版を選ぶときの注意

試験版は新しい変更を早く確認できる一方、導入後の表示や設定が安定版と同じとは限りません。検証用のユーザー環境や別の実行パスを用意し、codex --versionの結果を記録してから試すのが安全です。日常のリポジトリで使う版を決めるときは、公式リリースで「Latest」と表示される安定版を基準にし、試験版の番号を最新版と混同しないようにします。

Linuxへの導入前に確認すること

インストールコマンドを先に貼り付けるより、対応OS、CPU、メモリ、作業場所を先に確認したほうが失敗を減らせます。OpenAIのインストール資料は、Ubuntu 20.04以降、Debian 10以降を対応例として挙げ、メモリは最低4GB、推奨8GBとしています。Windows 11でLinuxを使う場合はWSL2という別の条件になるため、純粋なLinux環境と同じものだと決めつけないでください。出典: https://github.com/openai/codex/blob/main/docs/install.md

公式READMEには、Linux向けの単体バイナリとしてx86_64用とarm64用が示されています。IntelやAMDの一般的な64ビットPCならx86_64、対応するARM機ならarm64を選びます。CPUの確認はuname -mででき、x86_64ならx86_64向け、aarch64ならarm64向けを選ぶ目安になります。ディストリビューションの名前だけを見てファイルを選ばないことが大切です。出典: https://github.com/openai/codex/blob/main/README.md

対応OSとCPUを先に見る

次のコマンドで、カーネル、CPU、メモリの目安を一度に確認できます。

uname -a
uname -m
free -h

UbuntuやDebianの標準的な64ビット環境なら公式の導入手順をそのまま試しやすくなります。コンテナや特殊なディストリビューションでは、シェルの種類、証明書、プロキシ、ホームディレクトリの書き込み可否も確認します。必要条件を満たしているのに起動しないときは、まずcodex --versionが通るかを見て、モデルやリポジトリの問題と混ぜないようにします。

プロジェクトの場所と権限を決める

最初の検証には、失っても困らない小さなリポジトリか、変更前のコピーを使います。/etcやシステム全体の設定が置かれた場所で試すのではなく、利用者のホームディレクトリ配下に作業用フォルダーを置きます。Codexに求める作業範囲を狭くし、書き込みが必要なときだけ差分を確認する運用にすると、導入確認と本番の開発を分けられます。Linuxでは管理者権限で起動すれば何でも解決するわけではなく、むしろ対象範囲が広がるため、通常の利用者権限で始めるのが基本です。

サインイン方法を決める

公式READMEが案内する初回起動では、codexを実行して「Sign in with ChatGPT」を選びます。Plus、Pro、Business、Edu、EnterpriseなどのChatGPTプランで使う方法と、APIキーを用意して追加設定を行う方法は入口が異なります。個人のLinux端末でまず試すならChatGPTサインインが分かりやすく、組織の利用条件や請求を分けたい場合は公式の認証資料を確認します。出典: https://developers.openai.com/codex/auth

Step 1: 公式インストーラーで安定版を入れる

Linuxで最初に試しやすいのは、OpenAIがREADMEに掲載しているインストーラーです。端末を開き、公式URLを確認してから次のコマンドを実行します。

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

この方法では、公式の配布先からLinux向けの実行ファイルを取得し、利用できるコマンドとしてCodexを配置します。導入が終わったら、インストーラーの表示に従って新しいシェルを開くかPATHを読み直し、次の二つで確認します。

command -v codex
codex --version

command -vが何も返さない場合は、インストールに失敗したとは限りません。ユーザー用のbinディレクトリがPATHに入っていない可能性があるため、インストーラーが表示した配置先を確認します。codex --versionが動けば、次はサインインとプロジェクトの確認へ進めます。公式の導入例はMacとLinuxを同じコマンドで扱っていますが、LinuxのCPU向けファイルを自分で選ぶ必要がある場面では、次の単体バイナリ方式も候補になります。出典: https://github.com/openai/codex/blob/main/README.md

Step 2: npmで導入する場合の確認手順

npmを普段から使っているLinux環境では、公式パッケージをグローバルに入れる方法も選べます。

npm install -g @openai/codex
codex --version

この方法の利点は、普段のNode.jsパッケージ管理と同じ考え方で更新できることです。一方、Linux用の実行ファイルはCPUや配布パッケージに依存するため、npm installが終わった表示だけで導入成功と判断しないでください。command -v codex、codex --version、必要ならtype -a codexまで確認し、古い場所のCodexが先に呼ばれていないかを見ます。

公式READMEには、インストーラーとnpmの両方が掲載されています。両方を試すと複数のCodexがPATHに並ぶことがあるため、普段使う方式を一つに決め、版番号を記録しておくと更新時に混乱しません。npm方式でLinux向けパッケージの取得に失敗した場合は、同じコマンドを何度も繰り返す前に、ネットワーク、npmの設定、CPU向けパッケージの有無を確認します。出典: https://github.com/openai/codex/blob/main/README.md

Step 3: GitHub Releasesの単体バイナリを使う

Node.jsの導入を増やしたくない場合や、版を固定して検証したい場合は、公式GitHub ReleasesからLinux用アーカイブを取得できます。2026年10月3日時点で安定版として確認した0.160.0を例に、x86_64向けの流れを示します。

mkdir -p "$HOME/.local/bin/codex-0.160.0"
cd "$HOME/.local/bin/codex-0.160.0"
curl -L -o codex.tar.gz https://github.com/openai/codex/releases/download/rust-v0.160.0/codex-x86_64-unknown-linux-musl.tar.gz
tar -xzf codex.tar.gz
install -m 0755 codex-x86_64-unknown-linux-musl "$HOME/.local/bin/codex"

uname -mがaarch64なら、URL中のcodex-x86_64-unknown-linux-musl.tar.gzをcodex-aarch64-unknown-linux-musl.tar.gzに置き換えます。展開後のファイル名もアーカイブに含まれるCPU名に合わせて確認してください。$HOME/.local/binがPATHにない場合は、シェルの設定へ追加してから新しい端末でcommand -v codexを実行します。配布ファイルの名前はリリースごとに公式ページで確認し、検索結果の転載サイトから取得しないことが大切です。出典: https://github.com/openai/codex/releases

単体バイナリ方式は、どの版を使っているかがフォルダー名に残る点が便利です。更新するときは新しい版を別のフォルダーへ展開し、検査が終わってからPATHの向き先を変更できます。戻す必要がある場合も旧版のファイルが残るため、原因を追いやすくなります。ただし古い版を長く使う場合は、公式リリースの修正内容を確認し、利用条件と実際の版番号を記録しておきます。

Step 4: 初回起動と読み取り依頼を行う

インストール直後は、いきなり大きな変更を頼まず、起動とサインインが正常かを確かめます。作業対象のリポジトリへ移動してからcodexを起動し、表示された案内からChatGPTへサインインします。

cd "$HOME/src/sample-project"
codex

最初の依頼は、たとえば次のように変更を求めない内容にします。

このリポジトリを変更せずに調べてください。主要なディレクトリ、起動方法、テスト方法、注意すべき設定を短く説明してください。

この依頼で、Codexが現在のフォルダーを読めるか、必要なファイルを見つけられるか、応答が返るかを同時に確認できます。説明に見覚えのないディレクトリが含まれていたら、作業場所を間違えていないかpwdで確認します。返答が正しそうに見えても、READMEや設定ファイルと照合してから次の依頼へ進めます。端末で使えることと、プロジェクトの前提を理解していることは別なので、最初の読み取りを検査として扱うのがポイントです。

Step 5: 小さな変更を依頼し、差分を確認する

起動が確認できたら、変更範囲が明確な小さな作業を一つ頼みます。たとえば、既存のテストに説明コメントを追加する、READMEの誤記を一箇所直す、特定の関数にテストを一つ加える、といった内容です。依頼文には対象ファイル、変更してよい範囲、実行してほしい検査、変更しない範囲を書きます。

src/example.tsの入力チェックだけを確認してください。必要ならテストを一つ追加し、既存のAPIの形は変えないでください。変更後は該当テストの結果と、変更したファイル名を説明してください。

作業後は、Codexの説明だけで判断せず、端末から差分を確認します。

git status --short
git diff -- src/example.ts
git diff --check

テスト結果、差分、依頼内容の三つが一致しているかを見ます。意図しないファイルが変更されていたら、その場で保存せずに理由を聞き、必要な範囲だけに戻します。Codexは調査、編集、コマンド実行を一つの対話で扱えますが、取り込みの判断まで委ねる必要はありません。Linuxでの基本は、端末で見える変更を人が確認し、結果を記録してから次の作業へ移ることです。

Step 6: 更新するときは版番号と導入元をそろえる

公式インストーラー方式なら、READMEに掲載されている手順を再確認してから同じ導入経路で更新します。npm方式なら、npm install -g @openai/codexを実行したあとにcodex --versionを確認します。単体バイナリ方式なら、新しいリリースのLinux向けアーカイブを別フォルダーに展開し、CPU向けファイルとPATHの向きを確認します。

更新前に次の情報を控えておくと、問題が起きたときに比較できます。

command -v codex
codex --version
uname -m

安定版から試験版へ移る場合は、版番号だけでなく、どの導入経路で入れたかも一緒に記録します。たとえばnpmで入れたものを単体バイナリで上書きすると、次回の更新で別のファイルが変わる可能性があります。更新後に以前と挙動が違うときは、まず版番号とPATHの解決先を比較し、次に公式リリースの変更点を読んでから設定を見直します。出典: https://github.com/openai/codex/releases

Linuxで起きやすい問題と対処

Linuxでの導入トラブルは、Codexのモデル性能よりも、実行ファイルの置き場所、CPU向けパッケージ、端末の環境、通信のどこかで起きることが多いです。症状を「起動前」「サインイン時」「作業開始後」に分けると、見る場所が明確になります。まず版番号が返るかを確認し、版番号が返らない状態でプロジェクトやモデルを疑わないことが切り分けの基本です。ここでは端末で再現しやすい表示を起点に、確認するコマンドと公式情報へ戻る順番を整理します。

codex: command not foundと表示される

最初にcommand -v codexとecho "$PATH"を確認します。ユーザー用binディレクトリがPATHに含まれていなければ、インストーラーが表示した場所をシェルの設定へ追加し、新しい端末で再確認します。npmと単体バイナリを両方入れた場合はtype -a codexで候補をすべて表示し、意図したファイルが先に呼ばれる状態にします。修正後はcodex --versionまで通ることを確認してから、リポジトリへ移動します。

Missing optional dependencyが出る

npm方式でインストールが成功したように見えても、Linux向けの実行ファイルを取得できず、起動時に不足を知らせる場合があります。OpenAIの公式リポジトリには、通信中の取得失敗によってLinux x64向けパッケージが欠けたままになる事例が報告されています。npmの通信先、プロキシ、CPU、取得先への接続を確認し、再インストール後に必ずcodex --versionを実行します。改善しなければ、公式Releaseの単体バイナリへ切り替えると、取得したファイルを自分で確認できます。出典: https://github.com/openai/codex/issues/41283

X11とWaylandで操作が違う

0.160.0のリリースノートにある中クリック貼り付けは、対応するローカルLinux X11端末での機能です。Wayland、リモート接続、端末エミュレーターの設定によっては同じ操作にならないことがあります。機能が使えないからといってCodex全体の導入失敗と決めつけず、codex --version、通常の文字入力、サインイン、リポジトリの読み取りを順に確認します。端末固有の操作だけが問題なら、別の端末で同じ依頼を試して差を切り分けます。出典: https://github.com/openai/codex/releases/tag/rust-v0.160.0

サインイン後に作業対象が違って見える

サインインできても、現在のディレクトリが目的のリポジトリとは限りません。pwd、git rev-parse --show-toplevel、git status --shortを確認し、対象のルートを確かめます。プロジェクト外から始めた場合は、0.160.0で案内されているセッションの扱いが関係することもあります。作業対象を変更する前に、Codexへ現在地と読み取り範囲を説明させ、端末のパスと一致するかを確認します。

公式インストーラー、npm、単体バイナリの選び方

三つの導入方法は優劣だけで決めるものではなく、更新を誰が管理するか、版を固定する必要があるか、LinuxのCPUを明示したいかで選びます。迷ったら、まず公式インストーラーで安定版を入れ、codex --versionまで確認します。Node.jsを日常的に管理している人はnpm、検証環境で配布ファイルを固定したい人は単体バイナリが向いています。

導入方法を途中で変える場合は、古いCodexが残っていないかを先に確認します。type -a codexで複数の候補が表示されるなら、どのファイルを呼ぶかを決めてから作業します。更新のたびに方式を変えるのではなく、普段使いの方式と検証用の方式を分け、版番号と導入元を一緒に記録すると、Linuxでの差分を説明しやすくなります。

Codex CLI Linuxを使うときの確認基準

Codex CLIの導入が終わったかは、コマンドが存在するかだけでは判断できません。第一にcodex --versionが返ること、第二にChatGPTへのサインインまたは選んだ認証方法が完了すること、第三に意図したリポジトリを読み取れること、第四に小さな変更の差分と検査結果を自分で確認できることを順番に見ます。この四つがそろって初めて、Linuxの開発環境として使い始められます。

2026年10月3日時点では、0.160.0を安定版の基準として、0.162.0-alpha系は別枠の試験版として扱うのが分かりやすい選択です。公式READMEのLinux向け手順、公式インストール資料、公式リリースノートを順に照合し、CPU向けファイルと導入元を記録してください。Codexに任せる範囲を小さく始め、端末で見える差分と検査結果を確認する習慣を作れば、Codex CLI Linuxは長い開発作業を整理する実用的な入口になります。