NixでCodexをインストールする方法｜nixpkgsとflakeの違い

Nix で Codex を導入する 3 つの経路と全体像

Codex CLI の公式な導入手順は npm(npm install -g @openai/codex)または Homebrew が中心に案内されている(出典: https://developers.openai.com/codex/cli)。しかし NixOS ではグローバル npm の書き込み先が標準では用意されておらず、システム全体を設定ファイルで宣言的に管理する流儀とも合わない。そこで Nix ユーザーが選べるのが、nixpkgs 収録パッケージ・公式 flake・コミュニティ flake という 3 つの経路だ。nixpkgs 版は Nix コミュニティのメンテナーがビルド定義を保守しており、最も「Nix らしい」導入方法と言える。公式 flake は openai/codex リポジトリに同梱されているもので、常に最新のソースを直接ビルドする。コミュニティ flake は公式の配布バイナリをそのまま Nix で扱えるように包んだもので、ビルド時間ゼロで最新版に追従できる。どれを選んでも codex コマンドが使えるようになる点は同じで、違いは「誰がどの速さで更新するか」と「ソースビルドか配布バイナリか」に集約される。

なぜ今 Nix での導入が注目されるのか

背景には Codex CLI のリリース間隔の短さがある。安定版だけでも 2026 年 7 月 1 日に v0.142.5 が公開され、並行して次期 0.143 系列の先行版が続いている状況だ(出典: https://github.com/openai/codex/releases)。更新が速いツールほど「どの経路で入れると、どのくらいの鮮度で追従できるか」が実用上の差になる。加えて Nix には、環境をファイルに書き残して同じ状態を何台でも再現できるという利点があり、開発マシンを頻繁にセットアップし直す人や、チームで環境を揃えたい場面で Codex の導入もまとめて宣言しておきたいという需要が高まっている。

方法 1: nixpkgs の codex パッケージを使う

nixpkgs には codex という名前でパッケージが公式に収録されている。nixos-unstable チャンネル時点のバージョンは 0.142.3 で、openai/codex リポジトリのタグ rust-v0.142.3 から Rust 製の本体(codex-cli)をソースビルドする定義になっている(出典: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/by-name/co/codex/package.nix)。この定義の実務的にありがたい点は、単にバイナリを置くだけでなく周辺の配線まで済ませてくれるところだ。コード検索に使う ripgrep、Linux ではサンドボックス用の bubblewrap が実行パスに含まれるようにラップされ、bash・zsh・fish のシェル補完も同梱される。ライセンスは Apache 2.0 で、ビルド済みのものがバイナリキャッシュから落ちてくるため、通常は自分のマシンでのコンパイルは発生しない。

Step 1: コマンド一発で試す

まずは常用するかどうか決める前に試したい、という場合は次のいずれかで導入できる。

1. nix profile install nixpkgs#codex — flakes を有効にした環境での標準的な導入方法。
2. nix-env -iA nixpkgs.codex — 従来型のチャンネル運用をしている場合の書き方。
3. nix shell nixpkgs#codex — インストールせず一時的なシェルで試す方法。終了すれば環境に何も残らない。

導入後は codex --version でバージョンを確認し、codex を起動して ChatGPT アカウントでのサインインか API キーの設定を済ませれば使い始められる(出典: https://developers.openai.com/codex/cli)。

Step 2: NixOS / Home Manager で宣言的に管理する

常用を決めたら、設定ファイルに書いて宣言的に管理するのが Nix らしい運用だ。NixOS ならシステム設定の environment.systemPackages に pkgs.codex を追加して再構築する。ユーザー単位で管理したい場合や、NixOS 以外の Linux・macOS で Nix を使っている場合は、Home Manager の home.packages に pkgs.codex を加える方法が向く。どちらの場合も、マシンを乗り換えたときに同じ設定ファイルを適用するだけで Codex 込みの環境が再現でき、更新に問題があれば世代を巻き戻せるというロールバックの安心感も得られる。

nixpkgs 版の注意点: 最新版から少し遅れる

nixpkgs 版の唯一と言ってよい弱点は鮮度だ。上流の最新安定版が v0.142.5(2026 年 7 月 1 日)まで進んでいるのに対し、nixos-unstable の収録は 0.142.3 と、パッチ 2 つぶんの差がある(出典: https://github.com/openai/codex/releases)。メンテナーの更新とチャンネルのビルドを経由する構造上、数日から一週間程度の遅れは常態と考えておくとよい。なお直近のパッチはログ出力の修正など小規模な内容が中心のため、日常利用でこの差が問題になる場面は少ない。安定チャンネル(NixOS のリリース版)を使っている場合はさらに古いことがあるので、Codex だけ unstable から取る overlay を組むか、後述の flake 併用を検討したい。

方法 2: 公式リポジトリの flake を nix run で使う

openai/codex リポジトリのルートには flake.nix が同梱されており、Nix ユーザーはリポジトリを clone しなくても次の一行で Codex を起動できる(出典: https://github.com/openai/codex/blob/main/flake.nix)。

1. nix run github:openai/codex — main ブランチの最新ソースをビルドして起動する。
2. nix run github:openai/codex/rust-v0.142.5 — タグを指定して特定バージョンを使う。
3. nix profile install github:openai/codex — 気に入ったら profile に入れて常用する。

この flake は x86_64 / aarch64 の Linux・macOS 4 プラットフォームに対応し、codex-rs パッケージをデフォルト出力として提供する。バージョンは同梱の Cargo.toml から読み取られ、main ブランチではコミット付きの開発版表記になる仕組みだ。

ソースビルドゆえの注意

公式 flake の注意点は、配布バイナリではなくソースからのビルドである点だ。nixpkgs のようなバイナリキャッシュが効かないため、初回は Rust のコンパイルにそれなりの時間と CPU を使う。また main ブランチをそのまま追うと、リリース前の変更を含む開発版を使うことになる。「リリースされたばかりの新機能をタグ指定でいち早く試す」「Codex 本体に手を入れて動かしてみる」といった用途には最適だが、日常の道具として安定運用したいだけなら、次に述べるコミュニティ flake か nixpkgs 版のほうが手間は少ない。開発参加者向けには Rust ツールチェーン一式を揃えた devShell も定義されており、nix develop で開発環境に入れる。

方法 3: 配布バイナリを使うコミュニティ flake

「ビルドは待ちたくない、でも最新版にはすぐ追従したい」という要望に応えるのがコミュニティ製の flake だ。代表的なものが 2 つある。sadjow/codex-cli-nix は公式の Rust 製ネイティブバイナリをそのまま Nix パッケージとして包んだもので、毎時のペースで上流リリースへの追従が保たれており、Node.js への依存なしに複数プラットフォームのキャッシュ付きで導入できる(出典: https://github.com/sadjow/codex-cli-nix)。SecBear/codex-nix も同様に公式の配布済みバイナリをパッケージ化しており、NixOS・nix-darwin・Home Manager それぞれに組み込むためのモジュールを備えているのが特徴だ(出典: https://github.com/SecBear/codex-nix)。flake 入力として自分の設定に加えておけば、nix flake update のタイミングで Codex も最新リリースに揃う。ソースビルドが走らないため更新も速い。ただし nixpkgs 本体と違って個人メンテナンスのリポジトリである以上、保守が止まる可能性は頭の片隅に置き、動かなくなったら nixpkgs 版に戻れるようにしておくと安全だ。

導入後の初期設定と動作確認

どの経路で入れても、初回の設定は共通している。順に確認しよう。

1. codex --version でインストールされたバージョンを確認する。
2. 作業したいプロジェクトのディレクトリで codex を起動する。
3. 初回起動時に ChatGPT アカウントでのサインイン(Plus / Pro / Business などのプラン)か、API キーでの利用かを選んで認証を済ませる(出典: https://developers.openai.com/codex/cli)。
4. 簡単な指示を出して、コードの読み取りと提案が返ってくることを確かめる。

nixpkgs 版はシェル補完が同梱されているため、bash・zsh・fish であればサブコマンドの補完が最初から効く。設定ファイル(~/.codex/config.toml)の書き方やモデルの切り替えは通常のインストールと変わらないので、既存の解説がそのまま使える。NixOS 特有の注意としては、サンドボックス関連で必要になる bubblewrap が nixpkgs 版ではあらかじめラップ済みという点があり、自前でバイナリを置くよりトラブルが少ない。

どの方法を選ぶべきか — 判断の軸

最後に選び方をまとめる。判断の軸は「更新の鮮度」「導入の手軽さ」「保守の確実さ」の 3 つだ。日常の開発で安定して使いたい多数派には、nixpkgs の codex パッケージが第一候補になる。Nix コミュニティの保守下にあり、バイナリキャッシュが効き、依存の配線も済んでいるからだ。数日の遅れが気になる場面は実際には少ない。一方、リリース直後の新機能を追いたい人や 0.143 系列の先行版を試したい人は、公式 flake のタグ指定起動が便利だ。ビルド時間を許容できるなら最も確実に「その時点の公式ソース」を動かせる。ビルドを避けつつ最新へ追従したいなら、配布バイナリを包んだコミュニティ flake が中間解になる。迷ったら、常用は nixpkgs 版で固定し、新版の検証だけ nix run github:openai/codex/<タグ> で一時的に走らせる、という二段構えを勧めたい。環境を汚さず両立できるのは、まさに Nix ならではの利点だ。