openclaw - 💡(How to fix) Fix [Beta report] 2026.5.12-beta.3: Codex runtime loads, but OpenAI primary times out and fallback trace is inconsistent

Summary

After updating a macOS OpenClaw host from 2026.5.12-beta.2 to 2026.5.12-beta.3, the released beta.3 package and matching npm plugins installed successfully. The gateway is running on 2026.5.12-beta.3, channel status is healthy, and openclaw plugins doctor reports no plugin issues. The previous beta.2 Codex loader failure (MODULE_NOT_FOUND for codex-native-task-runtime) no longer appears during real agent execution.

The remaining issue is that the OpenAI/Codex primary route now reaches execution but times out, then falls back to Anthropic/Pi. The user-visible response succeeds only via fallback. The returned metadata is also inconsistent: agentMeta.fallbackAttempts records the failed OpenAI attempt, but executionTrace.attempts only includes the winning fallback attempt and executionTrace.fallbackUsed is false.

Environment

• OpenClaw before: 2026.5.12-beta.2
• OpenClaw after: 2026.5.12-beta.3
• Install type after update: global npm package
• Runtime platform: macOS arm64, Node 25.x
• Configured primary model: openai/gpt-5.5
• Intended runtime/harness: OpenAI Codex
• OpenAI auth mode shown in result metadata: auth-profile
• Report is sanitized: hostnames, IPs, local usernames, tokens, phone numbers, and private paths are omitted or replaced with placeholders.

Update result

The beta.3 package install completed and the updater synced npm plugins:

• core package: 2026.5.12-beta.3
• @openclaw/brave-plugin: 2026.5.12-beta.2 -> 2026.5.12-beta.3
• @openclaw/codex: 2026.5.12-beta.2 -> 2026.5.12-beta.3
• @openclaw/discord: 2026.5.12-beta.2 -> 2026.5.12-beta.3
• @openclaw/whatsapp: 2026.5.12-beta.2 -> 2026.5.12-beta.3

Post-update checks:

• openclaw --version reports OpenClaw 2026.5.12-beta.3 (cc46ca9)
• CLI and gateway versions match
• LaunchAgent is loaded and running
• gateway connectivity probe is OK
• channels are connected
• openclaw plugins doctor reports: No plugin issues detected.
• openclaw tasks audit reports warnings only, no errors

Codex smoke test

Command shape:

openclaw agent --agent main \
  --session-id beta512b3-codex-smoke-<timestamp> \
  --message "Reply exactly: BETA512B3_CODEX_OK" \
  --timeout 180 \
  --json

Result status was ok, and the visible reply was correct:

{
  "status": "ok",
  "result": {
    "payloads": [
      { "text": "BETA512B3_CODEX_OK" }
    ]
  }
}

But the winning provider/runtime was fallback, not Codex/OpenAI:

{
  "provider": "anthropic",
  "model": "claude-opus-4-7",
  "agentHarnessId": "pi",
  "fallbackAttempts": [
    {
      "provider": "openai",
      "model": "gpt-5.5",
      "error": "LLM request timed out.",
      "reason": "timeout",
      "status": 408
    }
  ]
}

The execution trace did not reflect that fallback correctly:

{
  "executionTrace": {
    "winnerProvider": "anthropic",
    "winnerModel": "claude-opus-4-7",
    "attempts": [
      {
        "provider": "anthropic",
        "model": "claude-opus-4-7",
        "result": "success",
        "stage": "assistant"
      }
    ],
    "fallbackUsed": false,
    "runner": "embedded"
  }
}

Severity-ranked findings

1. High: OpenAI/Codex primary route still does not complete

Beta.3 appears to fix the prior Codex module-load failure in the actual plugin-loader path, but the OpenAI primary attempt now times out and falls back. This means installations configured for openai/gpt-5.5 through the Codex runtime can appear healthy at the CLI level while actually running on the fallback Pi harness/provider.

Expected: simple direct smoke completes on openai/gpt-5.5 using the Codex harness.

Actual: simple direct smoke returns only after fallback to anthropic/claude-opus-4-7 / Pi.

2. Medium: fallback telemetry is internally inconsistent

The result contains an OpenAI timeout in agentMeta.fallbackAttempts, but executionTrace.attempts omits the failed OpenAI attempt and fallbackUsed is false. This makes automated health checks and operator reports misleading, because the top-level status is OK and the trace says no fallback even though the primary model failed.

Expected: executionTrace.attempts includes both the failed OpenAI attempt and the successful fallback attempt, and fallbackUsed is true.

Actual: trace shows only the Anthropic success and fallbackUsed: false.

3. Low/diagnostic: plain Node package export probe still fails for the private Codex task runtime subpath

From inside the installed @openclaw/codex package, a plain Node ESM import still fails:

node --input-type=module -e 'await import("openclaw/plugin-sdk/codex-native-task-runtime")'

Result:

ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath './plugin-sdk/codex-native-task-runtime' is not defined by "exports"

The package export check confirms no public export:

Boolean(packageJson.exports["./plugin-sdk/codex-native-task-runtime"]) === false

This may be intentional if beta.3 fixes the runtime through trusted loader aliases only. I am including it because it was the exact subpath involved in the beta.2 regression and remains a useful diagnostic distinction: real agent execution no longer fails with MODULE_NOT_FOUND, but plain package exports still do not expose the subpath.

4. Low: update-time doctor output briefly reported gateway/service unavailable although final service state was healthy

During the beta.3 update flow, the doctor step reported the gateway as not running / service not installed or not loaded. After the update completed, the LaunchAgent was loaded and running, CLI/gateway versions matched, and connectivity was OK. This looks like timing/order/reporting during update rather than a persistent failure, but it may be worth clarifying in updater output to avoid false alarms.

Regression comparison with beta.2

Beta.2 behavior observed previously:

• OpenAI/Codex route failed immediately with MODULE_NOT_FOUND
• error path involved root-alias.cjs/codex-native-task-runtime
• the response succeeded only by falling back to Anthropic/Pi

Beta.3 behavior now:

• no MODULE_NOT_FOUND in the agent smoke result
• OpenAI/Codex primary attempt is reached but times out with status 408
• response still succeeds only by falling back to Anthropic/Pi
• fallback trace metadata remains misleading

Suggested next checks

• Confirm whether the OpenAI/Codex timeout is an auth-profile/OAuth request issue, a Codex app-server issue, or a model transport timeout.
• Add a regression test that asserts a beta-migrated openai/gpt-5.5 Codex route completes without fallback.
• Add a metadata test for fallback attempts so executionTrace.fallbackUsed cannot be false when agentMeta.fallbackAttempts is non-empty and the winner differs from the requested primary.
• If the private task runtime subpath is intentionally loader-only, consider adding a diagnostic message that distinguishes "private alias not exported" from "runtime alias missing" to make future reports clearer.