Summary

openclaw models status --json reports missingProvidersInUse: ["openai"] when the active/default model is openai/gpt-5.5, even though the model is intentionally served through the Codex runtime and openai-codex OAuth is valid.

This is confusing because the active model path works. The status output makes it look like the current model is missing auth, when the missing auth only applies to direct OpenAI API/provider usage.

This looks related to #79131 and #83574, but this report is for the CLI openclaw models status surface rather than Telegram /model status or the picker label.

Environment

• OpenClaw: 2026.5.12 (f066dd2)
• Default model: openai/gpt-5.5
• Runtime/auth path: Codex runtime via openai-codex OAuth

Observed

A sanitized summary of openclaw models status --json shows:

{
  "defaultModel": "openai/gpt-5.5",
  "resolvedDefault": "openai/gpt-5.5",
  "imageModel": "openai/gpt-5.5",
  "allowed": [
    "qwen/qwen3.6-plus",
    "qwen/glm-5",
    "openrouter/xiaomi/mimo-v2-pro",
    "openai/gpt-5.5"
  ],
  "missingProvidersInUse": [
    "openai"
  ],
  "oauthProviders": [
    {
      "provider": "openai-codex",
      "status": "ok",
      "effectiveProfileCount": 1
    }
  ]
}

But a gateway smoke test of the same model succeeds and shows that the effective provider is openai-codex:

openclaw infer model run --gateway --model openai/gpt-5.5 --prompt 'Reply with exactly: OK' --json

Sanitized result:

{
  "ok": true,
  "provider": "openai-codex",
  "model": "gpt-5.5",
  "text": "OK"
}

Expected

models status should distinguish direct provider auth from effective runtime auth.

For a Codex-runtime setup where openai/gpt-5.5 is served via openai-codex OAuth, the command should not imply that the active model path is broken or unauthenticated.

Possible output semantics:

openai: direct OpenAI API auth missing; available via codex runtime / openai-codex OAuth

or omit openai from missingProvidersInUse when the configured runtime/auth plan can successfully serve the selected model.

Why it matters

After migration or setup, models status is a natural health-check command. Seeing missingProvidersInUse: ["openai"] sends users toward configuring a direct OPENAI_API_KEY, even when they deliberately use ChatGPT/Codex OAuth instead of direct API billing.

The current behavior creates a false-positive diagnostic path: the runtime is healthy, but the status command reports the canonical model provider as missing without explaining that the effective Codex runtime auth is available.