Codex stating new version of codex required when in most recent version

• Model changed to gpt-5.5 xhigh › continue ■ Error running remote compact task: {"detail":"The 'gpt-5.6-sol' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."}

Problem persists even when I switch to a new model.

Several others are having this issue.
For me it was resolved by uninstalling my homebrew install and reinstalling with npm.
I'm guessing they are the same so maybe just the act of installing/reinstalling fixing whatever was going wrong.
So my problem is resolved but I'll leave the bug open because it would be great for that flow to be fixed in the future.

I’m getting the same error-gpt-5.6-sol displays the message “a newer version is required,” even though I already had the latest version (0.144.0) installed. Reinstalling didn’t help at first, and the codex doctor command revealed the issue. The problem stemmed from two different things.

1. I had two installations of Codex. A simple npm install -g @openai/codex updated one copy (/usr/lib/node_modules), but the Codex that was actually running was a different one (in my NVM environment). Therefore, every reinstallation affected the wrong copy and didn’t change anything. codex doctor immediately points this out (“npm install will update the other installation”). It’s worth checking this before reinstalling anything.
2. The real cause of the problem turned out to be the model cache. The running codex app-server daemon was storing an outdated model directory and constantly overwriting the cache, which is why gpt-5.6-sol never appeared. Deleting the cache while the daemon was running didn’t work-it simply wrote it back.

Here’s what helped me solve the problem:

• Terminate the running codex processes (app-server + proxy) by PID
• Delete the model cache directories in the ~/.codex/cache folder (codex_app_directory, codex_apps_server_info, codex_apps_tools, remote_plugin_catalog)
• Restart Codex-it will restart the daemon and reload the catalog

After that, gpt-5.6-sol resolved and started normally. Login credentials and history remained intact; no re-login was required.
In short: First, run codex doctor to check for inconsistencies caused by a dual installation, then clear the model cache while the daemon is stopped, not while it is running.

@alesha-pro Thank You, So much solution worked

I reproduced the same user-facing failure on Linux with codex-cli 0.144.1 and ChatGPT authentication. This case adds evidence that the generic upgrade error can be caused by stale app-server/model-catalog state even when the installed CLI is current.

Observed split:

• A fresh codex exec -m gpt-5.6-sol process succeeded.
• The existing interactive/remote-control path still emitted Model metadata ... not found and the same 400 "requires a newer version of Codex" response.
• The persistent app-server had been running for about ten days.
• App-server logs repeatedly reported failed to refresh available models: timeout waiting for child process to exit.
• codex remote-control stop/start reported that the app server was running but was not managed by the current daemon.
• The default profile had previously used a model_catalog_json override. Removing that override fixed newly started processes, but the existing app-server retained stale state.

Recovery did not require reinstalling Codex, logging in again, or deleting caches:

1. Stop the stale app-server process.
2. Remove its orphaned control socket.
3. Run codex remote-control start --json.
4. Start a fresh interactive Codex session.

Afterward:

• codex app-server daemon version reported both CLI and app-server as 0.144.1.
• codex debug models returned full metadata for gpt-5.6-sol with upgrade: null.
• Both plain codex and codex -m gpt-5.6-sol selected Sol, and an interactive request completed successfully.

This suggests Codex could improve the failure path by detecting an unmanaged/stale app-server or catalog-refresh failure and recommending a daemon restart/catalog reload, instead of reporting only that the installed CLI must be upgraded.

Same issue here, via Zed + codex-acp.

Setup:

• Client: Zed (v0.144.1, macOS) using the codex-acp ACP adapter
• Traffic goes through a self-hosted API gateway (not OpenAI's endpoint directly), but the gateway is just forwarding the request/response unmodified — the 400 originates from upstream, not the proxy
• Model: gpt-5.6-sol
• Auth: OAuth

Reproduction pattern:
This error is not triggered on every request — it only happens when the conversation context is close to the limit and the client attempts an automatic remote compact. Fresh/short sessions with the exact same model work fine with no errors at all. The moment context usage gets high enough to trigger compaction, the compact request itself fails with:

The 'gpt-5.6-sol' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again.

This confirms it's specific to the /responses/compact code path, not general inference with this model.

Additional detail from gateway-side logs: the main /responses request that triggers compaction sometimes also gets a 400 with the same message before the compact call is even attempted, followed by the compact retry also failing (502 downstream). So it looks like both the compact endpoint and, in some cases, the standard endpoint reject gpt-5.6-sol once the payload/context crosses some size threshold — possibly unrelated to compact specifically, but to request size in general.

Workaround currently in use: starting a new session before context gets close to full, or switching away from gpt-5.6-sol for long-running sessions.

Would be good to know if this is being tracked/fixed upstream, or if there's a version pin that's supposed to resolve it — "upgrade to latest" doesn't seem to help since CLI is already current (as others have also reported).

I found the root cause and wanted to document it here in case it helps others.

Root cause

The issue was not that Codex CLI needed a newer version.

Instead, there were two separate problems on my machine.

1. CLI and app-server were running different versions

The CLI itself had already been updated to 0.144.0, but a long-running app-server process was still running an older version (0.142.5).

codex doctor and codex app-server daemon version helped identify this.

This app-server was a persistent code_mode_host instance rather than the normal managed daemon, so it wasn't stopped by the usual daemon management commands.

Its logs showed repeated model refresh failures, including:

failed to refresh available models: timeout waiting for child process to exit

As a result, it continued serving stale model metadata.

Interestingly, normal codex exec and interactive CLI sessions were not using this stale process—they started a fresh app-server from the current CLI binary—so only the persistent daemon exhibited the problem.

The fix was:

1. Stop the stale app-server process.
2. Clear the stale model cache (~/.codex/cache/...).
3. Start a fresh app-server.

After that:

CLI version == app-server version == 0.144.0

and GPT-5.6 models immediately became available.

---

2. Rollout state DB inconsistency

Separately, codex doctor reported rollout/thread inventory inconsistencies.

After inspecting the SQLite database directly, I found that archived sessions had been moved on disk, but the corresponding rollout_path values in the state database had never been updated.

Updating those records resolved all doctor warnings.

This issue was unrelated to GPT-5.6 availability, but I fixed it while investigating.

---

Verification

After fixing the stale app-server state, all GPT-5.6 models worked correctly:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

using Codex CLI 0.144.0.

So in my case the error message:

"The 'gpt-5.6-sol' model requires a newer version of Codex"

was misleading—the installed CLI version was already sufficient.

Hopefully this helps anyone who encounters the same symptoms.

Closing this issue since it is resolved on my machine.

I managed to fix it. There were two parts to the problem.

First, I had multiple Codex installations (same as the comment above describes), including npm and standalone versions. I removed all of them and installed Codex again from scratch using the official standalone installer.

The main issue, however, was the model cache. My Mac Codex app had an active remote connection to the EC2 instance. Because of that, the Codex app-server and proxy processes on EC2 kept restarting whenever I killed them. They were also restoring the old model cache, so deleting the cache alone didn’t work.

What fixed it:

1. Remove all npm and standalone Codex installations.
2. Reinstall Codex using the official standalone installer.
3. Close the Codex app on the Mac or disconnect its remote connection to EC2.
4. On EC2, find the running Codex processes:

pgrep -a -u "$USER" -f 'codex|app-server|proxy'

1. Kill the listed processes and confirm they don’t restart:

kill <PID1> <PID2>
pgrep -a -u "$USER" -f 'codex|app-server|proxy'

1. Delete the cached model data:

CODEX_DIR="${CODEX_HOME:-$HOME/.codex}"

rm -rf ~/.codex/cache

1. Start Codex again.

After that, GPT-5.6 appeared in the model list and worked normally. I didn’t need to log in again.

Additional Raspberry Pi 5 / Linux ARM64 reproduction

I reproduced the same user-facing failure on a Raspberry Pi 5 running Debian 12 (aarch64) with Codex CLI and the current native package both at 0.144.1.

The observed state before recovery was:

• The foreground CLI and installed ARM64 binary reported 0.144.1.
• A long-running app-server from a deleted temporary npm package directory was still active and its /proc/<pid>/exe --version reported codex-cli 0.142.0.
• ~/.codex/models_cache.json was stamped with client_version: 0.142.0 and contained no gpt-5.6-* entries.
• /usr/local/bin/codex resolved to the same current NVM/npm wrapper, so there was no second active installation explaining the version skew.

I stopped only the identified old app-server process group, renamed the model cache to a backup, and restarted Codex from the current installation. After recovery:

• All inspected active native Codex processes reported 0.144.1.
• The regenerated cache reported client_version: 0.144.1 and included Sol, Terra, and Luna.
• The following command succeeded twice with OK and exit code 0:

codex exec --ephemeral --skip-git-repo-check \
  --model gpt-5.6-sol --json 'Reply with exactly: OK'

I also checked the installed ARM64 package metadata, ELF target, and embedded version strings; all were consistent with 0.144.1. I found no evidence of an ARM64 packaging defect.

Important limitation: the stale process and stale cache were observed together and removed in the same recovery. I did not independently isolate which one was sufficient, and I did not capture filesystem audit data proving which PID wrote the cache.

This adds Raspberry Pi/Linux ARM64 evidence that the generic “requires a newer version” response can accompany local CLI/app-server version skew and stale model-catalog state. It may be useful for codex doctor to flag an unmanaged app-server whose reported version differs from the invoking CLI and provide a supported restart/catalog-refresh remediation.

Just to also note.... reboot your Linux box. But that is the easy way to get this to work for all you non-tech folks.

I updated the codex, then ran a command codex exec -m gpt-5.6-sol "Show model name" on my Linux box, and it fixed the issue.