Codex agent uses outdated nested CLI despite newer system Codex, causing Astra requests to fail

[iamnvt]

Describe the bug

Codex agents configured to use gpt-6-astra fail because Buzz's private codex-acp installation launches its nested Codex CLI 0.145.0, even when a newer, working Codex CLI is installed on the same machine.

The agent's saved configuration and buzz-acp startup log both confirmed model=gpt-6-astra. The reported UI symptom was "model card not found"; the underlying Codex logs explicitly identify an unsupported client version (quoted below).

Buzz 0.5.23 accepts the installed codex-acp 1.1.7 as available, but that adapter's nested Codex CLI is too old for the selected model. Restarting Buzz or reselecting the model does not change the executable the adapter launches.

Steps to reproduce

1. Use Buzz Desktop 0.5.23 with its private @agentclientprotocol/codex-acp installation at version 1.1.7 and nested @openai/codex at version 0.145.0. These are the observed installed versions; a fresh installation today may resolve different versions.
2. Leave CODEX_PATH unset in Buzz's agent environment. A newer system Codex CLI can already be installed; on this machine it was 0.155.1.
3. Configure a Codex-backed agent to use gpt-6-astra, start the agent, and send a simple prompt.
4. The agent launches the private nested Codex CLI 0.145.0 and the Astra request fails with the version error below.

Expected behavior

Buzz should validate the actual Codex executable used by its ACP adapter against the selected model's requirements. If that executable is too old, it should offer a supported update or runtime-selection path and show an actionable error identifying the affected Codex version.

A sufficiently new adapter or a newer system Codex installation should not by itself make an incompatible nested CLI appear ready for the selected model.

Version and platform

• Buzz version: 0.5.23
• OS: macOS 26.5.1 (25F80), Apple silicon / arm64
• ACP adapter: @agentclientprotocol/codex-acp 1.1.7
• Adapter's declared Codex dependency: @openai/codex: ^0.145.0
• Actual nested Codex CLI: 0.145.0
• System Codex CLI: 0.155.1, installed through Homebrew
• Selected model: gpt-6-astra
• Authentication: existing ChatGPT sign-in

Logs / additional context

The running process path before the workaround was:

~/Library/Application Support/Buzz/node-tools/lib/node_modules/@agentclientprotocol/codex-acp/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex app-server

Relevant Codex warnings, with unrelated process/session identifiers omitted:

Unknown model gpt-6-astra is used. This will use fallback model metadata.

startup websocket prewarm setup failed: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."}}

Relevant source in the installed Buzz release:

• MIN_CODEX_ACP_VERSION is 1.1.7, with availability determined by the adapter version.
• plan_adapter_install skips installation when that adapter version check passes.
• The underlying CLI installation step runs only when the CLI cannot be resolved.

These checks appear to miss the mismatch between the accepted adapter and the actual nested Codex executable it uses. I am not suggesting that every new Codex release must be installed automatically; the important missing behavior is compatibility validation and an actionable upgrade path.

Verified workaround

After quitting Buzz, set this environment override in its existing global-agent-config.json, preserving other settings:

"env_vars": {
  "CODEX_PATH": "/opt/homebrew/bin/codex"
}

Then reopen Buzz. On this machine that path resolves to Codex CLI 0.155.1.

Validation performed:

• Both running Codex-backed buzz-acp processes received the configured CODEX_PATH.
• Using Buzz's same installed ACP adapter with this override, a new ACP session selected gpt-6-astra[low] and listed Astra's supported reasoning levels.
• A direct ACP prompt asking for exactly BUZZ_ASTRA_OK returned that response with stopReason: end_turn.
• No adapter package replacement, authentication change, or permission widening was needed for this test. This was a local ACP connectivity test; it did not send a diagnostic message to a Buzz channel.

Potentially related symptoms: #7623. That report uses a different adapter version, so a shared root cause has not been confirmed.

[Keiran-James]

+1