[BUG] adversarial-review / review fail with HTTP 400 ('gpt-5.5 requires newer Codex') on CLI 0.130.0 #309

Activity

1. tgkim-openerd

   added a commit that references this issue on May 28, 2026

   docs(exploration): Phase B — suminerProxy fork eval + upstream issue …

   ...

   fa11783
2. Steve-ender commented on Sep 8, 2026

   

   Steve-ender

   on Sep 8, 2026

   More actions

   "requires a newer version of Codex" on Windows even after updating: check which codex.exe actually runs

   Additional Windows finding for this error: our Claude Code Codex plugin (1.0.6) failed with The 'gpt-6-astra' model requires a newer version of Codex, although CLI 0.153.4 was installed. The failed jobs were still running an older executable. This may help diagnose similar reports; it does not establish the cause of the original issue here.

   What we found on our Windows machine with the Codex desktop app installed:

   • %LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe reported codex-cli 0.130.0-alpha.5. A hashed subdirectory under that same bin directory contained a different executable reporting codex-cli 0.153.4. This is an observed installation layout, not a claim about how every app update behaves.
   • All eight inspected historical plugin jobs recorded cli_version: 0.130.0-alpha.5 in their saved session metadata, including the Astra failures. Installing newer npm packages had not established that those jobs used them.
   • Plugin 1.0.6 launches codex app-server by name through its inherited Windows shell/PATH and reuses a healthy workspace broker. A newer CLI in another terminal, or a changed PATH, does not upgrade a broker already running. --fresh creates a new thread, not a new broker.
   • Pinning the verified 0.153.4 directory in the plugin child's PATH and using separate CLAUDE_PLUGIN_DATA state produced a successful Astra task. Saved metadata confirmed CLI 0.153.4, originator Claude Code, model gpt-6-astra, and read-only sandbox; output was ASTRA_PLUGIN_OK. A background task that read a local document and returned a result also passed. The plugin used our existing ChatGPT login and normal configuration; no client identity impersonation was involved.

   Both executable selection and broker state were controlled in the successful test. We have not isolated which one accounted for every earlier failure.

   Read-only diagnostics in PowerShell, ideally in the environment that launches the plugin:

   Get-Command codex -All | Select-Object CommandType, Source, Definition
   where.exe codex
   codex --version
   
   $codexBinRoot = Join-Path $env:LOCALAPPDATA 'OpenAI\Codex\bin'
   if (Test-Path -LiteralPath $codexBinRoot) {
       Get-ChildItem -LiteralPath $codexBinRoot -Filter codex.exe -File -Recurse |
           ForEach-Object {
               [pscustomobject]@{
                   Path = $_.FullName
                   Version = (& $_.FullName --version | Out-String).Trim()
               }
           } | Format-List
   }

   Compare these paths/versions with the actual failed job's saved session_meta.cli_version. A version printed by a newly opened terminal does not prove the plugin's existing broker uses it. Do not select a binary solely because its folder looks newer.

   Our workaround uses a child-only PATH pinned to the verified executable and separate plugin data keyed on executable/plugin identity, with inherited broker endpoint variables removed. It leaves existing jobs running. Use that same runtime/data directory for subsequent status/result/cancel commands; changing CLAUDE_PLUGIN_DATA separates job history too. We did not need to restart the CAD application or kill all Codex processes.

   Suggestions for maintainers: expose the serving broker's executable/version in job diagnostics, support an explicit executable path, and detect runtime mismatches when reusing a broker. Offer a fresh compatible broker without terminating in-flight jobs. An explicit path option or an environment variable such as CODEX_EXE would be a proposed feature, not an existing option in the installed plugin we tested.

   This establishes one local cause of the error and a working recovery path. It does not establish the cause of other macOS/Linux reports or rule out separate availability/configuration problems.