taupe WebとAIと暮らし

Projects / 実践記録

Codexを日々使うならCLI更新前後の状態を点検しておくべき

Codexを日々使うならCLI更新前後の状態を点検しておくべき

本ページはアフィリエイトプログラムを利用しています

Codex CLIを更新する時、今まではバージョン番号だけ見て終わりにしがちでした。

でも、最近はそれだけだと少し不安になってきた。

Codexは、日々の作業にかなり入り込んできている。
ブログの下書き、WordPress確認、GitHub repoの整理、AIチーム運用、公開後の同期。
自分の場合、もう「たまに使うCLI」ではなく、作業環境の一部です。

今回の記事は、リリースノートの翻訳ではありません。
Codex CLIを更新する時に、更新前後で何を見ておくと安心かの実務ログです。

題材として、今回は自分の環境で 0.142.5 から 0.143.0 へ更新しました。

だから、バージョンが上がった時も、単に npm install -g して終わりにはしにくい。

更新前に何を見たか。
更新後に何が変わっていないか。
codex doctor は通るか。
pluginsやMCPまわりの変更を、自分の環境でどう受け止めるか。

そこまで見ておくと、あとで変な挙動が出た時に切り分けしやすい。

この記事では、2026年7月9日時点で、Codex CLI 0.143.0 へ更新した時の確認ログを整理します。

Codex CLI 0.143.0がstable releaseになった

OpenAI CodexのGitHub releaseで、0.143.0 が公開されていました。

release noteを見ると、今回は地味な更新ではありません。

目についたのはこのあたり。

  • remote pluginsがdefault-on
  • remote / local plugin versionの表示
  • npm marketplace sources
  • macOS / Windows system proxy対応
  • codex remote-control pair
  • MCP toolsのtool search default
  • ChatGPT-hosted MCP serversのsession authentication
  • Amazon Bedrock GPT-5.6 Sol / Terra / Luna support
  • 依存ライブラリとsecurity advisory対応

自分に関係がありそうなのは、特にplugins、MCP、proxy、remote-controlまわり。

CodexをCLIだけで完結させているなら、見た目の変化は小さいかもしれない。
でも、Codex app、thread運用、plugin、MCP、Chrome、WordPress、GitHubを組み合わせて使っていると、こういう変更は作業環境全体に効いてくる可能性がある。

なので、今回は「何が増えたか」より先に、「更新しても自分の環境が普通に動いているか」を見ることにした。

今回見たいのは、新機能より作業環境への影響

新しいrelease noteを見ると、つい機能名を追いたくなる。

remote plugins。
MCP tool search。
remote-control。
GPT-5.6。

どれも気になる。

でも、自分が最初に見たいのはそこではない。

毎日使っているCodexが、更新後も普通に動くか。
ローカルの状態に妙な変化がないか。
codex doctor でwarnやfailが出ないか。

この順番です。

特にCodexは、ただのCLIではなくなってきている。
ローカルのsessions、SQLiteログ、rollout履歴、plugins、MCP、認証状態、ネットワークまわりが絡む。

全部を手で追うのは面倒。
ただし、何も見ないのも怖い。

そこで今回は、更新前後で codex-healthkitcodex doctor を使いました。

codex-healthkit は、先日公開したmetadata-onlyの小さなCLIです。
詳しくは、Codexを日々使う人へ。ヘルスチェックCLI「codex-healthkit」を公開しました に書いています。

ここでは主役ではありません。
更新前後の状態を見るための道具として使います。

更新前にcodex-healthkitで状態を残した

まず、更新前の状態を軽く残しました。

実行したのは、このあたり。

codex-healthkit check --json
codex --version
npm list -g --depth=0

更新前の状態はこうです。

  • Codex CLI: codex-cli 0.142.5
  • npm global package: @openai/codex@0.142.5
  • codex-healthkit: 0.1.0-alpha.1
  • codex-healthkit status: ok
  • SQLite WAL: size-only checkで大きなspikeなし

ここで大事なのは、実ローカルのJSONをそのまま公開しないこと。

codex-healthkit はmetadata-onlyで、credentials、token files、cookies、SQLite contents、session transcript contentsを読まない設計にしています。
それでも、自分の環境のサイズや件数は、記事に全部貼る必要はない。

今回の記事では、状態確認に必要な範囲だけを書く。

0.142.5 だった。
healthkitは ok だった。
大きなWAL spikeは見えなかった。

そのくらいで十分です。

0.142.5から0.143.0へ更新した

更新はnpm global packageとして行いました。

npm view @openai/codex version
npm view @openai/codex@0.143.0 version dist.tarball
npm install -g @openai/codex@0.143.0

この時点で、npmのlatestは 0.143.0
target tarballも 0.143.0 を指していました。

実際のinstall結果は、短く言えば成功。

changed 2 packages in 5s

その後に codex --version を見ると、codex-cli 0.143.0
npm global packageも @openai/codex@0.143.0 になっていました。

ここまでは普通の更新です。

でも、ここで終わらせない。

更新後にもう一度状態を見る。
それが今回の主題です。

更新後にcodex doctorまで確認した

更新後は、次を確認しました。

codex --version
npm list -g --depth=0
codex-healthkit check --json
codex doctor

結果として、Codex CLIは 0.143.0
codex-healthkit は更新後も ok
SQLite WALも、size-only checkでは大きなspikeなし。

codex doctor も確認しました。

自分の環境では、結果はこうです。

17 ok · 1 idle · 2 notes · 0 warn · 0 fail

notesはありました。
たとえばrollout容量やsandbox状態のように、doctorが注意として見せてくれる情報です。

ただ、warnとfailは0。
installもconsistent。
state DB、log DB、goals DB、memories DBもintegrity ok。
rollout inventoryもDBとfilesが一致。

ここまで見られると、少なくとも更新直後に大きく壊れている感じはない。

もちろん、これは自分の環境での結果です。
すべての環境で同じとは限らない。

でも、更新前後の最低限の状態を残しておくと、あとから「いつから変だったのか」を考えやすくなります。

remote plugins default-onとMCPまわりは見ておきたい

今回の 0.143.0 で、自分が特に見ておきたいのはpluginsとMCPです。

release noteでは、remote pluginsがdefault-onになり、catalog rowsやnpm marketplace sources、remote / local versionsの表示が入ったと説明されています。

これは、Codexをplugin前提で使っている人には関係が大きい。

今までは「ローカルに何があるか」を見る感覚が中心だった。
でも、remote catalogやmarketplace sourceが自然に見えるようになると、導入候補が増える。
そのぶん、入れる前の判断も必要になります。

自分の場合は、最近 Codex用のヘルスチェックCLI「codex-healthkit」 を公開したばかりです。
pluginや外部toolを見る時も、まずは「何を読むのか」「外へ送るのか」「認証情報に触れるのか」を確認したい。

MCPまわりも同じです。

release noteでは、MCP toolsがtool searchをdefaultで使うようになったこと、ChatGPT-hosted MCP serversがsession authenticationを明示的に使えることが書かれています。

便利になる方向ではある。
ただ、便利になった時ほど、自分の環境では何が有効になっているかを見ておきたい。

Codex CLIの更新は、単にバージョン番号を見るだけでは足りない。
plugins、MCP、proxy、remote-controlのような周辺機能が動く時代になると、作業環境として点検する意味が増える。

GPT-5.6 supportは、使えるという意味ではない

もうひとつ、読者が気になりそうなのがGPT-5.6です。

0.143.0 のrelease noteには、Amazon Bedrock GPT-5.6 Sol / Terra / Luna supportが入っています。
さらに max reasoning effortへのsupportも書かれています。

ここは少し注意が必要です。

release noteにsupportがあることと、自分のCodex環境で今すぐGPT-5.6を使えることは別です。

OpenAIの公式記事では、GPT-5.6 seriesはlimited previewとして説明されています。
OpenAI Help Centerでも、preview accessは限定され、API、Codex、またはその両方のどれが承認されているかを確認するよう案内されています。

つまり、ここで言えるのはこのくらいです。

  • Codex CLI 0.143.0 のrelease noteには、Bedrock GPT-5.6 supportがある
  • GPT-5.6自体は限定previewとして扱われている
  • 自分の通常環境で使えるかどうかは、別途確認が必要

「GPT-5.6がCodexで使えるようになった」とは書かない。
少なくとも、自分の環境ではそう断定しない。

モデル名は目立つ。
でも、実務ではモデル名だけで判断しない方がいい。

使えるか。
どのworkspaceか。
APIなのかCodexなのか。
approved accountなのか。
どのprovider経由なのか。

そこを分けて見る必要があります。

codex-healthkitのcompareも、更新ログと相性がよさそう

今回の更新では、before / afterを手で見ました。

ただ、ちょうど codex-healthkit 側でも、--compare <previous-report.json> の対応がmainに入りました。

PR #6では、前回reportとの比較として、WAL、SQLite DB、active sessions、archived sessions、quarantine sizeなどのdeltaを出せるようにしています。

これはCLI更新と相性がいい。

たとえば、更新前にreportを残す。
更新後にもう一度reportを出す。
その差分を見る。

codex-healthkit check --json > before.json

# Codex CLIを更新する

codex-healthkit check --json > after.json
codex-healthkit check --compare before.json

こうすると、何が増えたのか、何が変わっていないのかを見やすい。

もちろん、これも万能ではない。
codex-healthkit はusage monitorではないし、quota dashboardでもない。
sessionの中身も読まない。
SQLiteの本文も読まない。

見るのは、あくまでmetadata。

でも、日常運用ではそれで十分な場面が多い。
むしろ、最初の確認としてはそのくらいがちょうどいい。

自分で試すなら、この順番がよさそう

自分の環境でCodex CLIを更新するなら、今後はこの流れにしようと思っています。

codex --version
codex-healthkit check --json > before.json

npm view @openai/codex version
npm install -g @openai/codex@latest
# versionを固定して確認したい場合は @0.143.0 のように指定する

codex --version
codex-healthkit check --json > after.json
codex-healthkit check --compare before.json
codex doctor

大事なのは、更新前の状態を残しておくこと。

更新後だけ見ても、何が変わったのか分かりにくい。
beforeがあると、afterの意味が少し見える。

ただし、before.jsonafter.json をそのまま公開しない方がいい。

codex-healthkit はmetadata-onlyですが、実ローカルのサイズや件数は、その人の作業環境の情報です。
共有するなら、必要な行だけ抜く。
issueに貼るなら、redacted exampleに近い形へ寄せる。

特に、credentials、tokens、cookies、SQLite contents、session transcript contentsは出さない。

これは、Codexに限らない。
AIエージェントを日常的に使うなら、作業ログを残すことと、公開してよい情報を分けることはセットです。

まとめ。Codex CLIの更新は、前後の状態も含めて見る

Codex CLI 0.143.0 に更新しました。

自分の環境では、0.142.5 から 0.143.0 へ更新でき、codex-healthkit はbefore / afterともに ok
codex doctor0 warn · 0 fail でした。

今回のreleaseには、remote plugins default-on、MCP tool search default、system proxy、remote-control pair、Bedrock GPT-5.6 supportなど、気になる変更が入っています。

ただ、この記事で一番書きたかったのは、新機能の紹介ではない。

Codex CLIを日々使うなら、更新前後の状態を残しておくと安心だということ。

バージョン番号だけ見る。
release noteだけ読む。
新しいモデル名だけ追う。

それでも概要は分かる。

でも、実務ではもう一歩見る。

更新前に何だったか。
更新後に何が変わったか。
doctorでwarnやfailが出ていないか。
pluginsやMCPのような作業環境に近い変更があるか。

そこまで見ておくと、Codexを使い倒す環境として少し扱いやすくなる。

便利なAIエージェントほど、モデルだけでなく、足元の環境も見ておきたい。

今回の 0.143.0 更新は、その確認を習慣にするちょうどよいタイミングでした。

あわせて読みたい本

CodexやAIエージェント運用を考える時に、近い文脈で読める本です。


参考・出典

続けて読む

次に読むなら、これ。

同じテーマの実践記録や、taupeの読み方へ進めます。

同じテーマAI活用近い実践記録をカテゴリから続けて読めます。サイトの読み方FAQ運用方針や、よくある質問を確認できます。taupeについてこのサイトについてどんな視点で作り、使い、運用しているかをまとめています。

Category

Author / Official hub

イシカワヒデカズの実践記録

Web制作、開発、AI活用、メディア運営の相談先は公式サイトにまとめています。