taupe Building, using, and running it.

Article

What to check before and after a Codex CLI upgrade

What to check before and after a Codex CLI upgrade

Reading the version number after an upgrade is not enough once a CLI has become part of your working environment.

Codex touches blog drafts, WordPress checks, repository tidying, agent operations, and post-publication sync in my setup. So an upgrade is not just npm install -g — it is a moment to record what the machine looked like before and after.

Originally published in Japanese on July 9, 2026. This English version was written in September 2026.

This is not a translation of release notes. It is the log of upgrading from 0.142.5 to 0.143.0 on July 9, 2026, and the routine I settled on afterwards. Codex CLI has since reached 0.153.4 (September 2026), so treat the versions here as a worked example, not a target.

Releases arrive faster than you can read them

0.143.0 shipped on July 8, 2026. 0.144.0 and 0.144.1 both landed on July 9 UTC — overnight my time, the same working day I was writing this up.

0.143.0 is not a quiet release. The items that mattered to my setup:

  • Remote plugins enabled by default, with npm marketplace sources and visible remote/local versions
  • Authentication and API traffic routable through macOS and Windows system proxies, including PAC and WPAD
  • codex remote-control pair for manual pairing codes
  • MCP tools using tool search by default; ChatGPT-hosted MCP servers able to use session authentication explicitly
  • Amazon Bedrock GPT-5.6 Sol, Terra, and Luna, with support for max reasoning effort
  • Dependency updates addressing security advisories

0.144.0 added usage-limit reset credits showing type and expiration, a writes app-approval mode, interactive authentication for MCP tools, and faster plugin skill loading. 0.144.1 was installer and code-mode fixes.

If you drive Codex purely from the CLI, the visible change may be small. If you combine the app, threads, plugins, MCP, a browser, WordPress, and GitHub, changes like these reach the whole environment.

Check the environment before chasing features

Release notes pull your attention toward feature names. What I want to know first is different: does the thing I use every day still work, has anything odd happened to local state, and does codex doctor come back clean.

Codex has stopped being just a CLI. Local sessions, SQLite logs, rollout history, plugins, MCP, authentication state, and networking are all in play. Tracking all of that by hand is tedious; tracking none of it is worse.

So I use codex-healthkit, a small metadata-only CLI I publish, together with codex doctor.

Record the before state

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

Before the upgrade: Codex CLI 0.142.5, npm global package @openai/codex@0.142.5, codex-healthkit 0.1.0-alpha.1 reporting ok, and no large SQLite WAL spike on a size-only check.

Do not publish the raw JSON. codex-healthkit is metadata-only by design — it does not read credentials, token files, cookies, SQLite contents, or session transcript contents. Even so, the sizes and counts in your report describe your working environment. The three facts above were all this article needed.

The upgrade itself

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

On July 9, 2026 npm’s latest was 0.143.0 and the target tarball matched. By July 10, npm latest had already moved to 0.144.1. If you are following along today, check @latest rather than pinning to a version from an article.

Install succeeded in seconds. codex --version reported codex-cli 0.143.0, and the npm global package matched. An ordinary upgrade — which is exactly where most people stop.

Check again afterwards, including doctor

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

codex-healthkit still reported ok. WAL showed no spike on a size-only check. codex doctor — documented as a diagnostic report covering local installation, config, auth, runtime, Git, terminal, app-server, and thread inventory — returned:

17 ok · 1 idle · 2 notes · 0 warn · 0 fail — the same counts I recorded in June, which is the point of having written the earlier number down.

The notes were informational, covering things like rollout size and sandbox state. Install consistent. State, log, goals, and memories databases all integrity-ok. Rollout inventory matching between the database and files.

This is one environment’s result and does not generalize. Its value is comparative: keeping a minimal record on both sides makes “when did this start going wrong” answerable later.

Plugins and MCP are the parts to look at

Remote plugins becoming default-on matters if you build on plugins. Until now the instinct was to check what exists locally. When remote catalogs and marketplace sources surface naturally, the pool of candidates grows — and so does the need to judge before installing.

My questions for any plugin or external tool are the same three: what does it read, does it send anything outward, does it touch credentials.

Same on the MCP side. Tool search by default and explicit session authentication for ChatGPT-hosted servers are both improvements. The more convenient something gets, the more worth knowing what is actually enabled in your environment.

“Model support in the release notes” is not “available to you”

0.143.0’s notes include Amazon Bedrock GPT-5.6 support. That is not the same as GPT-5.6 being usable in your Codex environment.

At the time I wrote this, GPT-5.6 was described as a limited preview with access approved separately for API, Codex, or both. So the accurate statement was: the release note mentions Bedrock GPT-5.6 support; GPT-5.6 itself is in limited preview; whether my normal environment can use it needs separate confirmation.

Update for this English version: that preview window closed almost immediately. GPT-5.6 Sol, Terra, and Luna became generally available on July 9, 2026 across ChatGPT, the API, and Codex — the day after 0.143.0 shipped. The specific caution is obsolete; the habit behind it is not.

Model names are the loudest part of a release note and the least reliable guide to what you can do. Availability, workspace, API versus Codex, account approval, and provider path are separate questions every time.

Comparing before and after automatically

I did this comparison by hand. Around the same time, PR #6 landed --compare <previous-report.json>, producing deltas for WAL, SQLite databases, active sessions, archived sessions, and quarantine size. It has since shipped: codex-healthkit is at v0.4.1 as of August 2026.

codex-healthkit check --json > before.json
# upgrade the Codex CLI
codex-healthkit check --json > after.json
codex-healthkit check --compare before.json

Worth stating what this is not: codex-healthkit is not a usage monitor or a quota dashboard, and it does not read session or SQLite contents. It reports metadata. For a first look after an upgrade, metadata is usually the right resolution.

The routine

codex --version
codex-healthkit check --json > before.json
npm view @openai/codex version
npm install -g @openai/codex@latest
codex --version
codex-healthkit check --json > after.json
codex-healthkit check --compare before.json
codex doctor

The load-bearing step is the first report. Looking only at the “after” leaves you unable to say what changed.

And do not paste before.json or after.json anywhere public. Extract the lines you need; if you are filing an issue, redact. Credentials, tokens, cookies, SQLite contents, and session transcript contents never go out. Keeping a work log and deciding what is publishable are two halves of the same practice.

The version number is the smallest part

0.142.5 to 0.143.0. codex-healthkit ok before and after. codex doctor at 0 warn, 0 fail.

The release brought remote plugins default-on, MCP tool search by default, system proxy support, remote-control pairing, and Bedrock GPT-5.6 support. But the point was never the feature list.

Reading the version and the release notes tells you the shape of a change. Recording the state on both sides tells you whether your environment survived it. The better an agent tool gets, the more the ground it stands on is worth checking.

References

Next

These notes come from running this setup daily.

About the author

Hidekazu Ishikawa

Hidekazu Ishikawa builds and runs web products with AI agents from Japan. Available for consulting on AI workflow design and web development.

Next

Keep reading.