はじめに
npm update で Codex CLI を上げたあと、リリースノートを読まずにそのまま使い始めることは多いと思います。ところが 0.161.0 では、同梱されているモデルカタログの既定モデルが GPT-6.1 Sol に入れ替わっています。手元で何も設定していなければ、更新した瞬間から別のモデルと話している可能性があるわけです。
では、更新後にどこを見れば「何が変わったか」を自分の環境で確かめられるのでしょうか。モデルの並び、opt-in 機能の既定値、MCP の認証導線、直前のパッチで直った起動失敗の条件は、どれも CLI のコマンドで確認できます。この記事では、それを 5 つの確認手順に整理しました。
対象読者は、Codex CLI を日常的に使っていて、0.161〜0.162 系へ更新した（またはこれから更新する）開発者です。
この記事で解決できること
- 0.161.0〜0.162.1 の 3 リリースで変わった点を、確認すべき順に把握できます
-
codex debug modelsで既定モデルの並びと文脈長の値を確かめられます - Daybreak など opt-in 機能が既定でどうなっているかを
codex features listで確認できます
実行した環境
検証は Linux のクラウド実行環境で行いました。@openai/codex@0.162.1 をリポジトリ外の一時ディレクトリにローカルインストールし、HOME と CODEX_HOME もその配下に隔離しています。ChatGPT へのサインインも API キーの設定もしていない、設定ファイルなしの状態です。そのため TUI を起動して対話する機能（/mcp login、音声デバイス選択、タスクの pin など）は動かしておらず、本文ではリリースノートの記述として扱います。
TL;DR
この記事の手順を終えると、次のことが自分の環境で判断できるようになります。
- 入っている Codex CLI が
latestの 0.162.1 か、alpha を拾っていないか - 同梱カタログで GPT-6.1 Sol が先頭（priority 1）にあり、その
context_windowが 272,000 であること（API のモデルページの 1,050,000 とは別の値） - Daybreak は既定オフで、有効にするには
cli_daybreakを明示する必要があること - MCP サーバーの認証を CLI の
codex mcp loginから行えること - バックグラウンドサーバーとの feature 設定差による起動失敗が、0.162.1 で直っていること
0.161.0〜0.162.1 で変わったこと
3 つのリリースは 10 月 7 日から 9 日にかけて続けて出ています。原典は openai/codex の GitHub Releases（rust-v0.161.0 / rust-v0.162.0 / rust-v0.162.1）です。筆者が確認した時点では、Codex の公式 changelog ページにこの 3 バージョンの項目は見当たりませんでした。
| バージョン | GitHub Releases 上の公開表示 | 主な変更（リリースノートの要約） |
|---|---|---|
| 0.161.0 | 10 月 7 日 | 同梱カタログと Amazon Bedrock カタログの既定モデルが GPT-6.1 Sol に。/mcp login <name>、音声のデバイス選択、Daybreak の opt-in 化 |
| 0.162.0 | 10 月 8 日 | managed Git worktree tools、agent Command Center のタスク pin、transcript のコピー、TUI のクリック可能 URL、custom provider の capability 設定（[model_providers.<id>.capabilities] の remote_compaction と external_web_access） |
| 0.162.1 | 10 月 9 日 | 複数行の非同期質問での TUI クラッシュ修正、バックグラウンドサーバーとの feature 設定差による起動失敗の修正 |
なお、「既定が GPT-6.1 Sol になったのは 0.161.0 が最初」とは言い切れません。第三者のリリースミラー 2 件には、0.159.1（9 月 29 日）のバックポートで先行していたという記載があります（GitHub Releases が取得できず、筆者は原典で確認できていません）。表の 0.161.0 の行は、同梱カタログと Bedrock カタログの既定、というリリースノートの記述に限った要約です。
capabilities のキー名は、0.162.1 に config.toml を読ませて確かめました。remote_compaction に不正な値を入れると expected unsupported or v2 というエラーで起動に失敗し、wire_api = "chat" は no longer supported で失敗しました。値の既定や意味は公式の PR（openai/codex#50459）の記述に基づくもので、筆者は動作までは確認していません。
利用者の手元に直接効くのは、0.161.0 の既定モデル変更と、0.162.1 の起動失敗修正の 2 つです。残りは使う人だけが意識すればよい追加機能なので、以降の手順でも既定モデルと起動まわりを先に確認し、追加機能は該当する項目でだけ触れます。
手順
5 つの確認は、上から順に「入っている版」「使われるモデル」「既定の機能」「認証」「既知の不具合」を見ていく流れです。
1. 版と dist-tag を確認する
最初に、手元の CLI がどの版かを確かめます。npm の dist-tag も合わせて見ておくと、意図せず alpha を入れていないかが分かります。
npm view @openai/codex dist-tags --json
npm view @openai/codex time --json
実行結果の抜粋は次のとおりです。
$ npm view @openai/codex dist-tags --json (抜粋)
"latest": "0.162.1",
"alpha": "0.163.0-alpha.5",
$ npm view @openai/codex time --json (抜粋)
"0.162.1": "2026-10-09T19:50:30.512Z",
"0.163.0-alpha.5": "2026-10-10T00:48:26.025Z",
0.162.1 の npm 公開は UTC で 10 月 9 日 19:50、日本時間では 10 月 10 日 04:50 です。GitHub Releases 側の表示は 10 月 9 日 19:44 で、表示のタイムゾーンは確認していませんが、数分の差に見えます。その約 5 時間後には 0.163.0-alpha.5 が alpha タグで出ているため、@alpha や範囲指定で入れている場合は 0.162 系ではない版が入りえます。
インストール後の版は codex --version で確認できます。
$ npm install @openai/codex@0.162.1
added 2 packages
$ codex --version
codex-cli 0.162.1
普段グローバルに入れている場合は npm install -g @openai/codex@0.162.1 のように版を明示しておくと、記事の内容と手元の挙動を突き合わせやすくなります。codex --help のサブコマンド一覧には update と doctor も並んでいますが、今回の検証ではこの 2 つの挙動までは確認していません。
2. 同梱カタログのモデルの並びを見る
既定モデルの変更は、codex debug models で確かめられます。このサブコマンドは CLI に同梱されたモデルカタログを出力するもので、認証も設定ファイルもない状態で実行できました。出力は JSON なので、そこから主なフィールドを抜き出して表にしました（codex debug models の出力から抜粋した行で、全件ではありません）。
| slug | display_name | visibility | priority | context_window | default_reasoning |
|---|---|---|---|---|---|
| gpt-6.1-sol | GPT-6.1-Sol | list | 1 | 272000 | low |
| gpt-6-astra | GPT-6-Astra | list | 2 | 272000 | low |
| gpt-6-sol | GPT-6-Sol | list | 3 | 272000 | medium |
| gpt-6-luna | GPT-6-Luna | list | 4 | 272000 | medium |
| gpt-5.6-sol | GPT-5.6-Sol | list | 5 | 272000 | low |
| gpt-5.6-terra | GPT-5.6-Terra | list | 8 | 272000 | medium |
| gpt-5.6-luna | GPT-5.6-Luna | list | 9 | 272000 | medium |
| gpt-daybreak-blue-latest | Daybreak Blue | hide | 11 | 272000 | low |
| gpt-daybreak-red-latest | Daybreak Red | hide | 12 | 372000 | medium |
| gpt-5.5 | GPT-5.5 | list | 13 | 272000 | medium |
| codex-auto-review | Codex Auto Review | hide | 43 | 272000 | medium |
gpt-6.1-sol が priority 1 で先頭にあり、すぐ下に gpt-6-astra が続きます。ただし、この出力は「既定モデルはこれです」と明示するものではありません。「priority が最小のものが既定になる」というのはカタログの並びからの推測で、リリースノートの「既定モデルが GPT-6.1 Sol になった」という記述と一致している、というところまでが確認できた範囲です。認証して TUI を起動し、実際に既定で選ばれるモデルを画面で確かめたわけではない点に注意してください。
もう 1 つ、表を見て気づいたのが default_reasoning の違いです。gpt-6.1-sol は low、gpt-6-sol は medium です（列名は筆者が整理したもので、JSON 上のキー名そのものではありません）。更新前の既定が gpt-6-sol だったかどうかは確認していませんが、モデルが変われば何も指定していないときの推論の強さもカタログ上は変わりえます。応答の速さや深さが更新前と違うと感じたら、モデルだけでなくこの値も疑ってみてください。
カタログの 272,000 と API の 1,050,000
筆者がこのカタログで一番引っかかったのは、context_window の値です。OpenAI の API ドキュメントにある GPT-6.1 Sol のモデルページには、次のように書かれています。
| 項目 | 値（API モデルページ） |
|---|---|
| model ID | gpt-6.1-sol |
| 入力 | $2 / 1M tokens |
| cached input | $0.10 / 1M tokens |
| cache writes | $2.50 / 1M tokens |
| 出力 | $10 / 1M tokens |
| 272K 超の入力 | 入力・cache の料金 2 倍、出力 1.5 倍（リクエスト全体に適用） |
| context window | 1,050,000 tokens（最大入力 922,000） |
| 最大出力 | 128,000 tokens |
| knowledge cutoff | 2026-04-30 |
出典: GPT-6.1 Sol（OpenAI API ドキュメント）
API のページでは 1,050,000 なのに、Codex CLI のカタログでは 272,000 です。約 3.9 分の 1 の値で、API の仕様だけを見て「Codex でも 100 万トークン級の文脈を渡せる」と考えると、前提がずれる可能性があります。上の表に抜粋した行では、ほぼすべてのモデルが 272,000 で、Daybreak Red だけが 372,000 です。一律の固定値ではなく、モデルごとに CLI 側で値を持っていると読めます。
この差がどこで効くのか（長い文脈を渡したときに CLI 側で 272,000 を境に圧縮や切り捨てが起きるのか）は、認証して実際に長文脈を流していないため検証できていません。言えるのは「CLI のカタログが持っている値は API の最大値とは別物」というところまでです。料金を見積もるときも、API ページの文脈長をそのまま前提にしないほうが安全です。なお、同じモデルページには「入力が 272K トークンを超えるプロンプトは、リクエスト全体で入力・cache の料金が 2 倍、出力が 1.5 倍になる」と書かれています。この 272K は CLI カタログの context_window 272,000 と同じ数値です。一致しているのは事実ですが、CLI がこの境界に合わせて値を決めているのかどうかは公式には書かれておらず、筆者も確かめていません。
前のモデルに固定したい場合
GPT-6.1 Sol への切り替えを避けたい場合は、モデルを明示します。Codex の changelog（2026-09-22 の GPT-6 Sol/Luna 展開の項目）では、CLI でのモデル指定方法として /model コマンドと codex --model gpt-6-sol の 2 つが案内されています。チームで同じモデルを使いたい場合も、既定に任せず明示しておくと更新のたびに挙動が変わるのを避けられます。
なお、モデルを指定しないときに選ばれるものは契約プランにも左右されます。公式の models ページは既定の名前を書かず「recommended model」と表現していて、GPT-6.1 Sol は Free と Go が対象外（Plus / Pro / Business / Enterprise / Edu が対象）とされています。また同ページによると GPT-5.5 は 2026 年 10 月 14 日に全プランで退役します（API は対象外）。いずれも公式ドキュメントの記述で、筆者は確認していません。出典: Codex models（公式）
3. opt-in 機能の既定値を確かめる
次に、機能フラグの既定値を codex features list で確認します。出力は「名前 / stage / 既定で有効か」の 3 列です。今回の更新に関係する行だけを抜き出しました。
$ codex features list (抜粋)
api_key_cyber_access_programs stable false
cli_daybreak under development false
in_app_voice stable true
worktrees stable true
cli_daybreak は under development で既定オフです。0.161.0 のリリースノートでも、Daybreak は opt-in で、有効にするには --enable cli_daybreak か features.cli_daybreak=true が必要、daybreak=true だけでは有効にならない、と説明されています。カタログでも Daybreak Blue と Daybreak Red は visibility が hide になっており、既定では表に出てこない扱いと整合しています。リリースノートによると、自動の Cyber ルーティングを使うには対象の ChatGPT サインインと OpenAI provider の組み合わせも必要です。Daybreak を有効にした状態の挙動は、今回は試していません。
in_app_voice は stable で既定オンです。0.161.0 で入った音声会話のマイク・スピーカー・入力チャンネルの選択は、リリースノートによれば設定がローカルに保存されます。音声デバイスが必要な機能のため、実動作は確認していません。
worktrees も stable で既定オンです。0.162.0 の managed Git worktree tools は、リリースノートでは「worktrees 機能が有効なとき、信頼済みのローカルプロジェクト向けに使える」と説明されています。既定でオンなので、信頼済みとして扱っているプロジェクトでは追加設定なしで対象になりうる、と読めます。worktree そのものの使い方や手動の git worktree との違いは、別記事の Codex CLI worktree 入門で扱っているので、ここでは「既定でオンになっている」ことの確認に留めます。公式の worktree ドキュメントにある保存先（$CODEX_HOME/worktrees）や保持件数は、デスクトップアプリ向けの説明のため、ここでは CLI の仕様として扱いません。
機能フラグ全体の stage と既定値の傾向は、以前の feature flags の記事で整理しました。更新のたびに全部を見直す必要はなく、リリースノートに出てきた名前だけを codex features list で引き当てれば十分です。
4. MCP サーバーの認証導線を確認する
0.161.0 では、セッション中に /mcp login <name> で MCP サーバーの認証ができるようになった、とリリースノートに書かれています。TUI 側のこのコマンドは今回起動していませんが、CLI のサブコマンドとしても認証の入口があることは確認できました。
codex mcp --help のサブコマンド一覧には、次のものが並んでいました（出力を整形した要約です）。
list / get / add / remove / login / logout
codex mcp login / codex mcp logout が並んでいるので、TUI を開かずにシェルから MCP サーバーの認証を済ませる経路もあります。codex mcp login を実際に実行したわけではなく、ヘルプで存在を確認しただけです。公式の MCP ドキュメントには、このサブコマンドに --no-browser、--scopes、--oauth-client-registration <AUTO|CIMD|DCR> があると書かれており、0.162.1 の codex mcp login --help でも確認できました（TUI の /mcp login が同じ挙動かは未検証です）。非対話での実行可否は未検証なので、スクリプトや CI で使えるかどうかは試して確かめてください。
Codex 本体の認証は codex login 側で、ヘルプには status サブコマンドと、--with-api-key、--with-access-token などのオプションが出ていました。更新後にまず認証が生きているかを見たいときは codex login status から始めると、モデルや MCP の問題と認証切れを切り分けやすくなります（このコマンドもヘルプで存在を確認しただけで、実行はしていません）。
なお、Codex の changelog では、2026-08-24 に codex mcp-server が非推奨になり、2026-09-05 に削除されたと案内されています。古い手順書で codex mcp-server を使っている場合は、今回の更新とは別にそちらの見直しも必要です。
5. 0.162.1 で直った起動失敗の条件を知る
最後は既知の不具合です。0.162.1 のリリースノートには 2 つの修正が載っています。
- 複数行の非同期質問で TUI がクラッシュする問題の修正（改行と完全なハイパーリンク宛先を保持・#51866）
- 実行中のバックグラウンドサーバーの feature 設定が CLI の既定と異なっていても起動できるようにする修正。互換性チェックは、CLI で明示的に feature を上書きしたときだけに適用される（#52648）
2 つ目は手順 3 と関係します。バックグラウンドで動いているサーバーと手元の CLI とで feature 設定がずれていると、修正前は起動自体に失敗することがありました。0.162.1 ではこのずれだけでは止まらなくなりますが、リリースノートの説明を読む限り、--enable などで明示的に feature を上書きした場合は引き続き互換性チェックの対象です。Daybreak を --enable cli_daybreak で有効にして起動する、といった使い方をする場合は、バックグラウンドサーバー側の設定と揃っているかを意識しておくと切り分けが早くなります。
0.162.0 には、このほかにも新規 TUI スレッドでのサーバー側モデル／reasoning 既定の扱い、apply_patch での CRLF の保持、Linux と Windows の sandbox、Retry-After の扱い、PowerShell インストーラの checksum といった修正が入っています。0.161 系で止めている場合も、0.162.1 まで上げておくほうがこれらの修正をまとめて取り込めます。
トラブルシューティング
Q1: 更新したのに codex --version が古いままの場合
グローバルとローカルの両方に入っていて、PATH 上で古いほうが先に見つかっている可能性があります。which codex でどのバイナリが呼ばれているかを確認し、npm install -g @openai/codex@0.162.1 のように版を明示して入れ直してください（この 2 つのコマンドは一般的な案内で、今回の検証では実行していません）。
Q2: 応答の傾向が更新前と変わった場合
手順 2 のとおり、既定モデルが GPT-6.1 Sol になり、カタログ上の default_reasoning は gpt-6.1-sol が low、gpt-6-sol が medium と異なります。前の挙動に戻したいときは codex --model gpt-6-sol で明示し、それでも差が残るなら reasoning の設定も確認してください。
Q3: Daybreak のモデルが一覧に出てこない場合
既定オフのため、出てこないのが正常です。リリースノートのとおり --enable cli_daybreak か features.cli_daybreak=true を指定します。daybreak=true という名前では有効になりません。
Q4: GPT-6.1 Sol の長文脈の料金が知りたい場合
公式モデルページに載っている基本料金（入力 $2、cached input $0.10、出力 $10 / 1M tokens）は確認できましたが、公式モデルページには、入力が 272K トークンを超えるプロンプトは、リクエスト全体で入力・cache の料金が 2 倍、出力が 1.5 倍になる、と記載されています。CLI がこの境界を超えたときにどう振る舞うかは未検証です。長文脈を前提に見積もる場合は、最新のモデルページで料金表を確認してください。
まとめ
冒頭の「更新後にどこを見れば何が変わったかを確かめられるか」への答えは、次の 5 つです。
-
npm viewの dist-tag とcodex --versionで、latestの 0.162.1 が入っているかを見る -
codex debug modelsで、GPT-6.1 Sol が priority 1 にあることと、context_windowが 272,000 であることを確認する -
codex features listで、Daybreak が既定オフ、worktrees と音声が既定オンであることを確認する -
codex mcp --helpとcodex login --helpで、MCP と本体の認証の入口があることを確認する（ログイン自体は未実行） - 起動失敗の条件が当てはまるなら 0.162.1 へ上げる（feature 設定差だけでは止まらなくなる）
この中で、リリースノートを読むだけでは見えなかったのが 2 番目の文脈長です。API のモデルページでは 1,050,000 トークンのモデルが、Codex CLI のカタログでは 272,000 として扱われています。手元のワークフローで長い文脈を渡しているなら、まず codex debug models で使っているモデルの値を見てみてください。API の割増レートの境界（272K）が CLI のカタログ値と同じ数字である点も含めて、272,000 を超えたときに CLI が実際にどう振る舞うかは、今回確かめきれなかった論点として残っています。
関連記事
- Codex CLIのexecをAPIキー認証でCIに組み込む
- Codex CLIのtoken budget、上限5でも1.1万トークン使われた
- GPT-Rosalind入門 — 創薬・ゲノム研究に特化したOpenAI初の生命科学AIの全貌
参考リンク
- openai/codex rust-v0.161.0（GitHub Releases）
- openai/codex rust-v0.162.0（GitHub Releases）
- openai/codex rust-v0.162.1（GitHub Releases）
- GPT-6.1 Sol（OpenAI API ドキュメント）
- Codex models（公式）
- Codex MCP（公式）
-
Codex changelog（GPT-6 Sol/Luna の展開、
codex mcp-serverの非推奨と削除の項目）