Summary

With canonical OpenAI defaults and native Codex runtime, a Telegram direct session drifts back from the desired user-facing model route openai/gpt-5.5 to openai-codex/gpt-5.5 after a live Codex turn.

This is not just the expected auth profile display. The /status model line is composed from session state as openai-codex/gpt-5.5, while the desired and configured route is openai/gpt-5.5.

Environment

• OpenClaw: 2026.5.28 (e932160)
• macOS: 26.5 (25F71)
• Channel: Telegram direct message
• Runtime: native Codex / OpenAI Codex
• Codex plugin: enabled (@openclaw/codex)
• Default model route: openai/gpt-5.5
• Auth profile: openai-codex:<account> OAuth profile

Relevant config / diagnostics

Static config looks canonical and passes validation:

• openclaw config validate succeeds.
• openclaw models status --plain reports openai/gpt-5.5.
• agents.defaults.model.primary = openai/gpt-5.5.
• No static openai-codex/gpt-* model route is configured.
• No models.providers.openai-codex override is configured.
• auth.order.openai = [ "openai-codex:<account>" ].
• plugins.entries.codex.enabled = true.
• codexDynamicToolsLoading = "searchable".

The auth split also appears intentional for this installed version:

• openclaw models auth list --provider openai shows openai-codex:<account> as usable under OpenAI.
• openclaw models auth list --provider openai-codex shows the same profile.
• openclaw models status --probe --probe-provider openai reports runtime auth along the lines of: openai via codex uses openai-codex ... status=usable.
• Running openclaw models auth login --provider openai --profile-id openai:<account> --device-code still launches the Codex device flow and stores/keeps the profile as openai-codex:<account>, not openai:<account>.

So openai-codex:<account> as an auth profile seems valid, but it appears to leak into the session's model provider.

Steps to reproduce

1. Configure OpenAI/Codex subscription auth so the canonical model route is openai/gpt-5.5.
2. Use native Codex runtime, either omitted runtime or agentRuntime.id = "codex".
3. Ensure the Codex OAuth profile is stored as openai-codex:<account> under auth.order.openai.
4. Run openclaw doctor --fix --non-interactive or manually reset the current session to openai/gpt-5.5.
5. Confirm status shows:
   • Model: openai/gpt-5.5
   • Auth: openai-codex:<account>
   • Runtime: OpenAI Codex
6. Send a Telegram DM turn through the live agent.
7. Check /status or session status again.

Expected behavior

The user-facing session model route should remain:

Model: openai/gpt-5.5
Auth: openai-codex:<account>
Runtime: OpenAI Codex

The auth/transport identity may be openai-codex, but it should not replace the logical model provider in session state.

Actual behavior

After a live turn, the same session drifts back to:

Model: openai-codex/gpt-5.5
Auth: openai-codex:<account>
Runtime: OpenAI Codex

Manually resetting the current session to openai/gpt-5.5 restores the desired display temporarily, but the drift returns after the next live run.

doctor --fix can clean stale openai-codex/* session pins, but the next live Codex run can re-persist modelProvider="openai-codex".

Source-level hypothesis from installed dist

From the installed 2026.5.28 dist files:

• agent-runner.runtime-*.js has a persistSessionUsageUpdate() path that writes params.providerUsed back into entry.modelProvider.
• providerUsed appears to derive from runResult.meta?.agentMeta?.provider.
• For native Codex turns, the Codex app-server metadata reports provider/transport as openai-codex with model gpt-5.5.
• That value then appears to be persisted into sessionEntry.modelProvider, producing the composed route openai-codex/gpt-5.5.

This looks like a semantic mix between:

• logical/user-facing model provider: openai
• auth/transport/provider used by Codex OAuth: openai-codex
• model id: gpt-5.5

Related issue

Possibly related but not identical to #90021. That issue is about explicit agentRuntime.id="openclaw" appearing to switch into Codex runtime. This report is for the native Codex runtime path, where Codex runtime is expected, but the session model route itself drifts from openai/gpt-5.5 to legacy-looking openai-codex/gpt-5.5.

Question

Should sessionEntry.modelProvider preserve the requested logical provider (openai) instead of the returned Codex auth/transport provider (openai-codex)?

Alternatively, should status/session composition normalize openai-codex metadata back to openai when the selected route is canonical openai/gpt-* and the openai-codex:<account> value is only the auth profile?