Summary

/new started a fresh Telegram direct-chat session on openai-codex/gpt-5.3-codex even though the configured default model was openai-codex/gpt-5.4, and I could not find evidence of a persisted per-chat model override for that conversation.

This looks like a session reset/bootstrap model-selection bug or stale model-resolution path.

Environment

• OpenClaw version: 2026.4.11
• Channel: Telegram
• Chat type: direct chat
• Configured default model: openai-codex/gpt-5.4
• Configured fallbacks include: openai-codex/gpt-5.3-codex, openai-codex/gpt-5.3-codex-spark

Expected behavior

When /new (or /reset) starts a fresh session for a direct chat, the new session should initialize on the configured default model (openai-codex/gpt-5.4) unless there is an explicit persisted session override for that chat.

Actual behavior

The fresh session initialized on gpt-5.3-codex before the first assistant reply.

Evidence

From the new session transcript (~/.openclaw/agents/main/sessions/e4805bdb-e163-4aba-b345-91dfc1433d5f.jsonl):

• 2026-04-15T00:33:20.591Z
  • {"type":"model_change", ..., "provider":"openai-codex", "modelId":"gpt-5.3-codex"}
• 2026-04-15T00:33:20.600Z
  • {"type":"custom", "customType":"model-snapshot", ..., "modelId":"gpt-5.3-codex"}
• The first assistant greeting in that session was generated with "model":"gpt-5.3-codex"

The session was only later switched to gpt-5.4 after a manual /model openai-codex/gpt-5.4 command from the user.

A later snapshot in the same transcript shows:

• 2026-04-15T01:38:06.753Z
  • {"type":"custom", "customType":"model-snapshot", ..., "modelId":"gpt-5.4"}

Why this seems unexpected

1. openclaw status reported the default direct-session model as gpt-5.4.
2. The local config (~/.openclaw/openclaw.json) had agents.defaults.model.primary = openai-codex/gpt-5.4.
3. I inspected ~/.openclaw/agents/main/sessions/sessions.json for the Telegram chat entry and did not find an obvious stored modelOverride, pinned gpt-5.3-codex, or similar explicit per-chat model field.
4. Earlier Telegram-linked session transcripts I sampled were starting on gpt-5.4, not gpt-5.3-codex.

Because of that, this does not currently look like a straightforward case of a previously pinned session override being preserved across /new.

Repro sketch

I do not yet have a minimal deterministic repro, but the observed flow was:

1. Telegram direct chat with the main agent
2. Send /new (or trigger the fresh-session startup path)
3. Observe that the newly created session transcript begins with model_change -> gpt-5.3-codex
4. First assistant reply is generated on gpt-5.3-codex
5. Manual /model openai-codex/gpt-5.4 switches it back to the configured default model

Suspected area

Possibly one of:

• session reset/bootstrap model resolution
• stale session snapshot/bootstrap cache interaction during /new
• fallback model being selected during reset despite no visible provider failure
• mismatch between effective default model resolution and the new-session initialization path

Notes

Relevant changelog entries suggest there has already been some churn in this general area:

• "Sessions/reset model recompute: clear stale runtime model..."
• "Gateway/session bootstrap cache invalidation ordering..."
• "Sessions: preserve overrides on /new reset"

This report may be another edge case in that family.