Summary

The /model picker in Telegram (and presumably other channels) labels the OpenAI provider entry with 🔑 api-key (env: OPENAI_API_KEY) even when auth.order.openai is configured to route exclusively through an OAuth (Codex) profile and no openai:default API-key profile is declared in auth.profiles.

This is misleading: users who have explicitly removed the API-key fallback to avoid silent per-token billing still see the picker advertise api-key auth as if it were the active mode. It undercuts the cost-control intent of trimming auth.order.

Environment

• OpenClaw v2026.5.16-beta.7
• Channel surface: Telegram /model

Configuration (relevant excerpt)

"auth": {
  "profiles": {
    "opencode:default": { "provider": "opencode", "mode": "api_key" },
    "anthropic:manual": { "provider": "anthropic", "mode": "token" },
    "openai-codex:aaajiao@gmail.com": { "provider": "openai-codex", "mode": "oauth" }
    // No `openai:default` profile is declared
  },
  "order": {
    "openai": ["openai-codex:aaajiao@gmail.com"]
    // Only the OAuth profile — no api-key fallback
  }
},
"models": {
  "providers": {
    "openai": {
      "baseUrl": "https://api.openai.com/v1",
      "models": [
        { "id": "gpt-5.5", ... },
        { "id": "gpt-5.4", ... },
        { "id": "gpt-5.4-mini", ... }
      ]
    },
    "openai-codex": { ... }
  }
}

Observed

/model in Telegram displays:

Models (openai · 🔑 api-key (env: OPENAI_API_KEY)) — 3 available

The openai provider entry is labeled with api-key auth even though auth.order.openai references only the OAuth profile and no openai:default profile exists.

Expected

Either:

1. The picker label should reflect the auth that auth.order.openai actually resolves to (here: 🔑 oauth (openai-codex:aaajiao@gmail.com)), or
2. If the openai provider has no resolvable profile in the configured order, the entry should be hidden or labeled with an explicit "no configured auth" warning rather than implying api-key is available.

Why it matters

Users trim auth.order deliberately to prevent silent fallback to per-token billed paths. When the picker label contradicts the configured order, there is no channel-surface way to verify the cost-control change took effect. It also creates an "is this a label bug or did my config not apply?" diagnostic ambiguity.

Verified: display-only mismatch

Manual selection of an openai/* model from this picker dispatches via the OAuth (Codex) profile as expected — /status after the pick shows 🔑 oauth (openai-codex:aaajiao@gmail.com). Routing correctly honors auth.order. The bug is purely on the picker's display side: the label rendering reads the provider's intrinsic default auth mode (api-key for the openai provider catalog with baseUrl: https://api.openai.com/v1) instead of the auth that auth.order.<provider> actually resolves to for that user.

Fix target: the channel /model picker's per-provider auth label rendering should resolve through auth.order.<provider> (and the configured auth.profiles) before falling back to the provider's intrinsic default auth mode.