Observed behavior

When testing Telegram against a Codex-backed OpenClaw gateway, Telegram /status shows the active session is working through OAuth:

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

But Telegram /model status reports the browseable providers as unauthenticated:

Current: openai/gpt-5.5
Default: openai/gpt-5.5

[codex] endpoint: default auth: missing
• codex/gpt-5.5

[openai] endpoint: default auth: missing
• openai/gpt-5.5

This is confusing because normal Telegram agent replies work, and /status correctly shows usable OAuth via the Codex runtime.

Expected behavior

Telegram /model status should report effective runtime auth for Codex-backed models, or otherwise make clear that provider auth is missing only for direct provider use. For example, with agentRuntime.id=codex and an openai-codex OAuth profile, the command should avoid implying the active openai/gpt-5.5 path is unauthenticated.

Possible acceptable output:

[openai] auth: via codex runtime / openai-codex OAuth

or a separate runtime-auth line that explains the current model is served through Codex OAuth.

Local evidence

From ~/.openclaw/openclaw.json:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-5.5"
      },
      "models": {
        "codex/gpt-5.5": {},
        "openai/gpt-5.5": {}
      },
      "agentRuntime": {
        "id": "codex"
      }
    }
  }
}

From ~/.openclaw/agents/main/agent/auth-profiles.json:

• auth profile provider: openai-codex
• auth type: oauth
• access/refresh token present

CLI openclaw models status --json sees the richer auth picture:

• providersWithOAuth: includes openai-codex (1)
• Codex effective auth is synthetic/plugin-owned

Root cause hypothesis

Telegram /model status appears to use the model-picker/provider surface rather than the effective runtime-auth surface:

• src/auto-reply/reply/directive-handling.model.ts builds model status from picker providers.
• It calls resolveAuthLabel(provider, ...) for each picker provider.
• src/auto-reply/reply/directive-handling.auth.ts resolves auth by the exact provider name, e.g. openai or codex.
• The Telegram output then prints auth: missing for those provider labels.

In this setup, the actual usable auth is under openai-codex, while the model picker lists openai/gpt-5.5 and codex/gpt-5.5. So the command reports direct provider auth as missing even though the active Codex runtime can execute successfully.

Acceptance criteria

• Telegram /model status distinguishes direct provider auth from effective runtime auth.
• For agentRuntime.id=codex with an openai-codex OAuth profile, it no longer reports the active model path as simply auth: missing.
• Output remains truthful if direct openai API-key auth is absent.
• Add or update tests for the Codex-runtime + openai-codex OAuth case.
• Existing direct-provider auth status behavior remains covered.