openclaw - 💡(How to fix) Fix [Beta report] 2026.5.10-beta.1 update: Codex OAuth model rewrite and follow-up diagnostics [1 comments, 2 participants]

Summary

This is a sanitized beta update report for 2026.5.10-beta.1, tested as a follow-up to the 2026.5.9-beta.1 Codex harness/model issue and the maintainer request to verify latest main/beta behavior. The host is a macOS arm64 OpenClaw install using OpenAI through Codex OAuth only, with no direct OpenAI API key configured. External channels and representative cron jobs were exercised after the update.

Final state after local workaround: OpenClaw is running 2026.5.10-beta.1; gateway is healthy; Discord and WhatsApp are connected; representative cron jobs are ok; and a direct agent smoke test succeeds on openai-codex/gpt-5.5 through the pi runtime with no fallback. The main regression below still reproduced immediately after the beta update and required manual config/cron repair.

Severity-ranked findings

High: updater/doctor rewrites Codex OAuth model IDs to direct OpenAI model IDs

On an OAuth-only OpenAI/Codex install, the update path rewrote working Codex model references from openai-codex/gpt-* to openai/gpt-*. After update, the default agent model became openai/gpt-5.5, representative cron payloads were also rewritten to openai/gpt-5.5, and direct agent execution failed the OpenAI primary route because no direct OpenAI API key exists on this host.

Observed primary-route failure, sanitized:

No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth; OpenAI agent model runs use openai/gpt-* through the Codex runtime. Set OPENAI_API_KEY only for direct OpenAI API-key surfaces.

The agent command returned status: ok only because fallback to Anthropic succeeded. The execution trace showed the attempted model as openai/gpt-5.5, an auth failure on that route, and a fallback winner on the Anthropic provider. This means the beta can appear healthy while silently not using the intended Codex/OpenAI primary model.

Manual workaround was to restore:

agents.defaults.model.primary = openai-codex/gpt-5.5
main/cron primary = openai-codex/gpt-5.5
mini-cron primary = openai-codex/gpt-5.4-mini
agent model maps = openai-codex/gpt-* with agentRuntime.id = pi
cron payload models = openai-codex/gpt-5.5

After restoring those values and restarting the gateway, a direct smoke test succeeded with provider openai-codex, model gpt-5.5, runtime pi, and fallbackUsed: false.

Medium: update restart path still emits a stale-binary warning

The update completed successfully from 2026.5.9-beta.1 to 2026.5.10-beta.1, but the restart portion printed a warning that config had been written by 2026.5.10-beta.1 while the current command was still running 2026.5.9-beta.1. It then reported that the gateway already showed the updated version and skipped a redundant restart.

This did not break the final install, but it is confusing in a beta validation flow and can make it harder to distinguish a healthy handoff from a mismatched CLI/service path.

Medium: update interrupted a running cron job and left unclear status

During service restart, one running cron job was marked failed on startup. Immediately after the update, a representative cron job showed status: error with lastError: null and failures: 0, which made the failure mode hard to interpret. After the model repair and manual trigger, the same job recovered to ok.

It may be worth either draining/pausing running cron work during update, or preserving a clearer failure reason when a run is interrupted by an update/restart.

Medium/Low: cron run --expect-final returned after enqueue rather than final completion

For two representative jobs, openclaw cron run <id> --expect-final --timeout 180000 returned quickly with an enqueue payload instead of waiting for final completion:

{ "ok": true, "enqueued": true, "runId": "manual:<job-id>:<n>" }

The help text says --expect-final should wait for final response. This made post-update cron verification more manual than expected. Also, cron run does not accept --json even though it prints JSON-shaped output, while cron runs requires --id; some CLI discoverability polish would help testers.

Low: plugin/update diagnostics are noisy but not obviously fatal

The npm plugin update reported repeated peer dependency relinks and a Brave manifest/package-name mismatch warning. plugins doctor later reported no plugin issues, but also emitted a deprecated plugin runtime warning for config.loadConfig().

These did not block the update, but the warnings are useful cleanup candidates because beta testers may read them as install drift.

Low / pre-existing or not attributed to this beta

Post-update diagnostics still showed a restrictive plugins.allow compatibility warning, a gateway token SecretRef unavailable in the doctor command path, orphan transcript/session route state, a bootstrap file near the configured size limit, and task audit warnings. These were observed during beta validation but are not clearly regressions introduced by 2026.5.10-beta.1.

External channels were connected after the update. Some Discord message-tool validation errors appeared in logs during testing, but I am not attributing those to the beta without a cleaner reproduction.

Reproduction outline for the primary issue

1. Start from an OpenClaw install authenticated to OpenAI via Codex OAuth only, with no direct OpenAI API key.
2. Use a working pre-update config where agent and cron models reference openai-codex/gpt-5.5 and openai-codex/gpt-5.4-mini through the pi runtime.
3. Run openclaw update --channel beta to 2026.5.10-beta.1.
4. Inspect agent defaults and cron payloads; they are rewritten to openai/gpt-5.5 / openai/gpt-5.4-mini.
5. Run a direct agent smoke test against the main agent.
6. Observe the primary OpenAI route fail with a missing API key / Codex OAuth routing error, followed by successful fallback to another provider.
7. Restore openai-codex/gpt-* model IDs and pi runtime mappings, repair cron payload models, restart gateway, and rerun the smoke test.
8. Observe successful execution on provider openai-codex, model gpt-5.5, runtime pi, with no fallback.

Expected behavior

For OAuth-only Codex users, update/doctor should not automatically rewrite working openai-codex/gpt-* agent model IDs to direct openai/gpt-* IDs unless the direct OpenAI API-key route is actually configured and intended. If the canonical public model name is now openai/gpt-*, the runtime resolver still needs to preserve the Codex OAuth harness path or migrate the config to an equivalent representation that continues to use Codex OAuth rather than direct OpenAI API-key auth.