Summary

After the OpenClaw 2026.6.1 Codex migration, legacy openai-codex/* model references are supposed to become canonical openai/* model references with agentRuntime.id = "codex".

That route is functionally correct, but it is hard to verify from the model picker / models.list surface when the selected model visually looks like a plain OpenAI model. In a real upgrade, this made it easy to miss stale legacy route state in a live Telegram direct session.

Real environment

• OpenClaw: official 2026.6.1 upgrade path from a 5.x install
• Runtime shape: native Codex runtime with preserved OAuth/subscription auth
• Channel shape: Telegram direct session using the main agent
• Intended route after migration: openai/gpt-5.5 with agentRuntime.id = "codex"
• Privacy note: direct chat ids, IPs, OAuth account ids, and tokens are intentionally redacted

Actual behavior observed

A new smoke session could look healthy after migration, while the existing real Telegram direct/main session still failed with:

Unknown model: openai-codex/gpt-5.5

The stale route was not obvious from the model picker/model-list surface because the repaired route also appears as openai/gpt-5.5 unless runtime metadata is visible separately.

Expected behavior

When a model choice is configured as an OpenAI model but routed through the Codex runtime, the Gateway/UI model surface should make that runtime visible while preserving the canonical selected model value.

For example, a repaired route should be observable as:

{
  "provider": "openai",
  "id": "gpt-5.5",
  "name": "gpt-5.5",
  "agentRuntime": {
    "id": "codex",
    "source": "model",
    "label": "OpenAI Codex"
  }
}

This lets operators distinguish:

• plain openai/gpt-5.5
• openai/gpt-5.5 routed through Codex
• stale openai-codex/* session/config state
• explicit OpenClaw/default runtime overrides

Why this matters

Without visible runtime metadata, the safe 6.1 migration path is harder to audit:

1. A newly-created smoke session can pass.
2. A real existing Telegram/direct session can still contain stale openai-codex/* state.
3. The healthy canonical route still displays as openai/gpt-5.5 unless runtime metadata is surfaced.
4. Operators can think migration is complete while real sessions still fail.

This is an observability/diagnostic gap around a migration and runtime routing boundary, not a request to reintroduce openai-codex/* as the user-facing provider route.

Related work

PR #90328 proposes exposing configured model runtime metadata through models.list and the model picker so openai/gpt-5.5 can show OpenAI Codex when it is routed through the Codex runtime.

Related context: #84032, #90036, #90047.