⚠️ Codex CLI 0.154.0 Can Stop Your AI Coding Agent From Launching — The 5-Second Check Before You Upgrade

:warning: Codex CLI 0.154.0 can stop your AI coding agent from launching — the 5-second check that tells you before it happens

What this is about: Codex CLI is OpenAI’s coding agent that runs in your terminal. People who self-host wire it to their own proxy, scripts or tool servers. Update 0.154.0 (9 Sep 2026) quietly deletes one command those wirings sometimes call — codex mcp-server — and after the update the agent stops launching with no message about why.

The prize: one line in your terminal, five seconds, and you know upgrade or hold. Both answers come with their command below.

:magnifying_glass_tilted_right: CHECK

rg -n --hidden 'codex[[:space:]]+mcp-server' ~/.local/bin ~/.config ~/.codex 2>/dev/null

:green_circle: Empty output → upgrade: npm install -g @openai/[email protected]
:red_circle: Any match → hold, repoint that launcher, then upgrade
:fast_reverse_button: Broke anyway → npm install -g @openai/[email protected], then fully restart Codex

:compass: Running Codex through a custom OpenAI-compatible proxy? The removal does not touch you. Pin the provider and model in config anyway — 0.154.0 makes fresh and forked sessions fall back to server defaults when nothing is pinned.

🧾 The other 12 changes in 0.154.0 — the 2 red ones bite self-hosters

:red_circle: Fresh sessions and forks fall back to server model defaults when no model is explicitly selected — pin it.
:red_circle: A rejected MCP tool call is not replayed after re-authentication — your controller has to retry it, or the job looks stalled.

:white_circle: Existing sessions discover newly installed plugin tools
:white_circle: Skills and hooks refresh after plugin upgrades or rollbacks
:white_circle: MCP OAuth refresh is coordinated; login challenges are surfaced
:white_circle: Remote resumes and forks preserve saved permissions
:white_circle: Approval authorization survives compaction more reliably
:white_circle: Approvals invalidated by later instructions are rejected
:white_circle: A session open in another app shows a read-only transcript and retries without losing the draft
:white_circle: Isolated Git worktrees via --worktree and /worktree (experimental)
:white_circle: Codex version is included in command and turn metadata

Official notes: Codex changelog

✅ Pre-upgrade checklist for production boxes

☐ codex --version recorded
☐ effective config + session data backed up — rollback is not a backup
☐ the grep above run over every launcher and service
☐ provider, model and reasoning level of production sessions written down
☐ fresh, resumed and forked sessions resolve to the intended model
☐ MCP auth expiry + manual retry tested
☐ a test plugin upgraded and rolled back with a session open
☐ approvals tested before and after compaction
☐ /worktree tried only in a disposable repo
☐ rollback rehearsed on copied session data — worktrees written under 0.154.0 are one-way

:warning: Codex CLI 0.154.0 Warning: Check Self-Hosted and MCP Integrations Before Updating

OpenAI released Codex CLI 0.154.0 on September 9, 2026.

This release removes the deprecated:

codex mcp-server

command.

Do not update blindly

If your self-hosted Codex proxy, launcher, wrapper, systemd service, container, IDE integration, or automation invokes codex mcp-server, upgrading to 0.154.0 will break that part of your setup.

Before updating, search your configuration and scripts for:

codex mcp-server

A basic Linux search might look like:

rg -n --hidden 'codex[[:space:]]+mcp-server' \
  ~/.local/bin ~/.config ~/.codex /etc/systemd 2>/dev/null

If the search finds an active command, service, or launcher dependency, remain on your current working Codex version until you have identified and tested a supported replacement.

Important clarification

This does not necessarily mean every self-hosted OpenAI-compatible model proxy will break.

If your configuration only points Codex at a custom API endpoint through model_provider, base_url, or a launcher-injected provider—and never invokes codex mcp-server—this specific removal may not affect it.

The danger applies to installations that actually depend on the removed command. Check first instead of guessing.

Other relevant changes in 0.154.0

The release also changes several behaviors important to self-hosted and long-running Codex installations:

  • Running sessions can discover newly installed plugin tools.

  • Skills and hooks can refresh following external plugin upgrades or rollbacks.

  • MCP OAuth refresh is coordinated and login challenges are surfaced.

  • A tool call rejected because authentication is required is not automatically replayed.

  • Remote resumed and forked sessions preserve saved permissions.

  • Fresh sessions and forks use server model defaults unless a model is explicitly selected.

  • Approval authorization survives conversation compaction more reliably.

  • Approvals invalidated by later instructions or answers should be rejected.

  • Experimental isolated worktree support was added through --worktree and /worktree.

  • Codex version information is exposed in command and turn metadata.

Shared so nobody gets paged for a removed command. — Mikey_LikesIT / BCBC

5 Likes

This is a good reminder — silent removals of deprecated commands are the worst kind of breakage, because the first hour of “debugging” is just you assuming your own config is wrong.

My rule for any tool that runs my daily workflow: never upgrade on a workday, and keep the exact install command for the known-good version saved in my notes so I can roll back without hunting through changelogs. I do the pre-upgrade search too — running the rg check before upgrading costs five seconds and has saved me more than once.

The rollback advice here is solid as well. Thanks for posting this, pinning first and upgrading on your own schedule is definitely the move with self-hosted agent setups.

1 Like

I learned this the hard way with another agent tool last month, so I now keep a small test alias instead of upgrading blindly. My habit is to pin the exact version in a scratch venv, run the mcp-server grep check you mentioned, and only then roll it out to my main setup. I also snapshot my config directory before any upgrade, which saved me twice when a minor release renamed a flag. The five-second check here is a nice addition to that routine, because silent breakage after an update is the worst kind. Thanks for writing this up, it is going straight into my upgrade checklist.

So did I. It was my inspiration to write this thread.