Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Follow-up agent runs fail with "Unknown model: codex-cli/gpt-5.4" while direct CLI execution succeeds.

Steps to reproduce

1. Configure agents.defaults.model.primary as codex-cli/gpt-5.4
2. Start openclaw-gateway
3. Send a message that triggers a normal agent response (direct run)
4. Send a follow-up message in the same conversation (same session/lane)

Expected behavior

Follow-up runs use the same model and succeed, consistent with direct runs where "cli exec: provider=codex-cli model=gpt-5.4" is observed.

Actual behavior

Follow-up runs fail with:

• FailoverError: Unknown model: codex-cli/gpt-5.4
• reason=model_not_found
• decision=candidate_failed
• Followup agent failed before reply

Direct runs in the same environment succeed and log:

• cli exec: provider=codex-cli model=gpt-5.4

OpenClaw version

2026.4.8 (gateway reports this at startup)

Operating system

Linux (Ubuntu VPS)

Install method

Global Node.js install (openclaw installed under /usr/lib/node_modules/openclaw)

Model

gpt-5.4

Provider / routing chain

codex-cli → runCliAgent (CLI backend)

Additional provider/model setup details

agents.defaults.model.primary is set to codex-cli/gpt-5.4

cliBackends includes codex-cli

Direct execution consistently routes through CLI and succeeds, confirmed via:

cli exec: provider=codex-cli model=gpt-5.4

Logs, screenshots, and evidence

Failing follow-up path:

FailoverError: Unknown model: codex-cli/gpt-5.4
reason=model_not_found
decision=candidate_failed
Followup agent failed before reply

Working direct path:

[agent] cli exec: provider=codex-cli model=gpt-5.4

Impact and severity

Affected systems: Telegram channel using codex-cli as primary model
Severity: Blocks follow-up responses in active conversations
Frequency: Always reproducible before local patch
Consequence: Follow-up messages fail and no reply is delivered to the user

Additional information

A local runtime patch that bypasses resolveModelAsync(...) for provider === "codex-cli" resolves the issue:

• Direct runs continue to work
• Follow-up runs succeed
• No further "Unknown model" or "model_not_found" errors observed

The failure appears limited to the follow-up / embedded path, not the direct CLI execution path.

Some plugins report requiring >=2026.4.9 while the host reports 2026.4.8.