背景
7/10 に gpt-5.6 sol がリリースされました。（日本時刻）
私の環境では、Mac mini 上のプロジェクトを、MacBook から SSH 経由で操作しています。
Codex CLI は npm で更新済みでした。
Mac mini 上で Codex Desktop App を直接開いた場合は gpt-5.6 が選択できたのですが、MacBook からSSH接続した場合は gpt-5.6 が選択できませんでした。
- Mac Mini で直接開いた場合
- MacBook から Mac Mini のプロジェクトにSSH経由で開いた場合
結論
原因は、codex コマンド本体ではなく、裏で動いている codex app-server が古いバージョンのまま残っていたことでした。
具体的なバージョンは以下です。
| 項目 | バージョン |
|---|---|
| Codex CLI | 0.144.1 |
| app-server | 0.141.0 |
CLI は更新済みでしたが、SSH 経由で使われていた app-server が古かったのです。
確認方法
同じ症状に当たったら、まず CLI と app-server のバージョン差を確認してください。
実行するコマンド:
codex --version
codex app-server daemon version
codex doctor
codex --version だけでは足りません。
見るべきなのは、実際に動いている app-server のバージョンです。
今回確認できた原因
codex app-server daemon version の出力を見ると、CLI と app-server のバージョンがずれていました。
実行したコマンド:
codex app-server daemon version
出力:
{
"status": "running",
"managedCodexPath": "/Users/<USER>/.codex/packages/standalone/current/codex",
"managedCodexVersion": null,
"socketPath": "/Users/<USER>/.codex/app-server-control/app-server-control.sock",
"cliVersion": "0.144.1",
"appServerVersion": "0.141.0"
}
見るべきポイントはここです。
{
"cliVersion": "0.144.1",
"appServerVersion": "0.141.0"
}
codex コマンド本体は新しいですが、実際に SSH 経由で使われていた app-server は古い状態でした。
さらに managedCodexPath は npm で入れた codex ではなく、次の standalone バイナリを指していました。
~/.codex/packages/standalone/current/codex
つまり今回の原因は、npm 版 CLI の更新漏れではなく、SSH / remote-control 側で使われる standalone app-server の更新漏れでした。
ここでいう standalone app-server は、npm や Homebrew で入れた codex コマンドとは別に、~/.codex/packages/standalone/current/codex 配下に置かれていた Codex の実行バイナリを指しています。
今回のポイントは、ターミナルで実行している codex は 0.144.1 でも、app-server がこの standalone 側の古い 0.141.0 から起動していたことです。
対処
まず通常の restart を試します。
実行するコマンド:
codex app-server daemon restart
codex app-server daemon version
期待する出力:
{
"cliVersion": "0.144.1",
"appServerVersion": "0.144.1"
}
restart で停止できない場合は、ソケットを掴んでいるプロセスを確認します。
実行するコマンド:
lsof -nU | grep app-server-control
出力:
codex-aar 1897 <USER> 13u unix ... /Users/<USER>/.codex/app-server-control/app-server-control.sock
codex-aar 1897 <USER> 28u unix ... /Users/<USER>/.codex/app-server-control/app-server-control.sock
対象が Codex app-server であることを確認してから、該当 PID を止めます。
実行するコマンド:
kill 1897
その後、新しい CLI から app-server を起動し直します。
実行するコマンド:
codex app-server daemon start
codex app-server daemon version
これで MacBook から SSH 接続しているプロジェクトを開いて、gpt-5.6 が選択できるようになっていれば完了です。
補足: なぜ Desktop App では問題なかったのか
ここは公式仕様として確認したわけではなく、今回の観測からの推測になります。
同じ Mac mini 上でも、Desktop App と SSH 経由 CLI が同じ app-server を見ているとは限りません。
今回の状態は、次のように考えると説明しやすいです。
| 利用経路 | 見ていたもの |
|---|---|
| Mac mini 上の Desktop App | Desktop App 側の更新済みランタイム、または別経路の app-server |
| MacBook から SSH した Codex CLI |
~/.codex/app-server-control/app-server-control.sock を掴んでいる古い standalone app-server |
そのため、Desktop App では新しいモデルを選べるのに、SSH 経由 CLI では古いモデル候補しか出ない、という差が出たと考えられます。
補足: 再起動で直る場合と直らない場合
「PC を再起動したら直った」というケースもあります。
ただし、今回のケースでは Mac mini を再起動しても直りませんでした。
違いはおそらくここです。
| 状態 | 再起動で直るか |
|---|---|
| 新しい app-server バイナリは既にあり、古いプロセスだけが残っている | 直ることがあります |
| standalone app-server 自体が古い | 直りません |
| 起動設定が古い standalone path を指している | 直りません |
再起動は古いプロセスを終了させることはできます。
しかし、ディスク上の standalone app-server が古いままなら、再起動後も同じ古い app-server が起動するだけなので改善しません。
まとめ
今回のポイントは次の3つです。
-
which codexやcodex --versionだけでは不十分です -
codex app-server daemon versionで app-server の実バージョンを確認します - CLI と app-server のバージョンがずれていたら、app-server の残留プロセスや standalone バイナリを疑います