Summary

After configuring OpenAI models/providers to use the OpenClaw runtime, a new/reset Telegram DM session initially appears to be set to "OpenClaw Default", but after the first message the session appears to run through the OpenAI Codex / Codex app-server path.

The active config explicitly sets OpenAI runtime policy to openclaw, so this looks like either a runtime-policy resolution issue, UI/session-state mismatch, or Codex auth/transport side effect.

Environment

• OpenClaw config last touched version: 2026.5.28
• @openclaw/codex: 2026.5.28
• bundled @openai/codex: 0.134.0
• Channel: Telegram direct message
• Model alias: gpt
• OpenAI provider API: openai-codex-responses
• Codex plugin enabled: true

Relevant config

Active config contains:

• models.providers.openai.agentRuntime.id = "openclaw"
• agents.defaults.models["openai/gpt-5.5"].agentRuntime.id = "openclaw"
• agents.list[<agent>].models["openai/gpt-5.5"].agentRuntime.id = "openclaw"
• agents.list[<agent>].model.primary = "gpt"
• models.providers.openai.api = "openai-codex-responses"

Steps to reproduce

1. Complete OpenAI Codex subscription OAuth.
2. Configure OpenAI provider/model runtime policy to OpenClaw.
3. Run /reset or /new.
4. Run openclaw doctor --fix.
5. Confirm the session/runtime UI shows "OpenClaw Default".
6. Send the first message to the agent over Telegram DM.
7. Check session/runtime state.

Expected behavior

If agentRuntime.id = "openclaw" is explicitly configured for the selected OpenAI model/provider, the session should remain on the OpenClaw runtime unless another explicit runtime override exists.

Actual behavior

The first message creates Codex app-server state and the trajectory records the run as openai-codex.

Observed evidence:

• First user message contains:

  • __openclaw.mirrorIdentity = "...:prompt"
  • idempotencyKey = "codex-app-server:...:prompt"

• Codex app-server binding file is created immediately with:

  • model = "gpt-5.5"
  • authProfileId = "openai-codex:<redacted>"
  • createdAt = "2026-06-03T18:48:09.414Z"

• Runtime trajectory session.started records:

  • provider = "openai-codex"
  • modelId = "gpt-5.5"
  • modelApi = "openai-codex-responses"
  • data.authProfileId = "openai-codex:<redacted>"
  • data.threadId = "..."

• Session index still shows logical model provider as OpenAI and no runtime override:

  • modelProvider = "openai"
  • agentRuntimeOverride = null
  • agentHarnessId = null
  • authProfileOverride = "openai-codex:<redacted>"
  • authProfileOverrideSource = "auto"

Assumed diagnosis / hypothesis

This may be caused by Codex OAuth/auth profile or openai-codex-responses transport identity influencing the effective runtime path before, or independently from, explicit agentRuntime.id = "openclaw" policy resolution.

I have not confirmed the exact source-level cause. The evidence only shows that configured runtime policy and observed first-turn runtime/session artifacts diverge.

Proposed checks / acceptance criteria

Could maintainers confirm the intended behavior for this combination?

• logical provider openai
• API openai-codex-responses
• auth profile openai-codex:*
• runtime policy agentRuntime.id = "openclaw"

Possible regression checks:

• Explicit agentRuntime.id = "openclaw" should remain effective even when the selected auth profile is openai-codex:*, if that is intended behavior.
• Codex app-server bindings should not be created unless the effective runtime is actually Codex app-server.
• UI/session runtime labels should clarify whether they are showing logical model provider, auth profile provider, transport provider, or agent runtime.

Question

Is this expected behavior when using OpenAI Codex OAuth with openai-codex-responses, or should explicit agentRuntime.id = "openclaw" prevent Codex app-server session binding?