openclaw - 💡(How to fix) Fix /model switch to codex-app-server runtime (e.g. openai/gpt-5.5) drops all Telegram conversation context (related to #80760) [1 pull requests]

Summary

When a user issues /model openai/gpt-5.5 (or any other codex-app-server-runtime model) from a Telegram DM, all subsequent turns answered by that model behave as if the session had no prior conversation. There is no context-engine plugin involved (no LCM / Lossless Claw). The model talks confidently and self-consistently while missing all but the current prompt, and OpenClaw shows no UI signal that this happened.

This is closely related to (and possibly the same root cause as) the locked issue #80760, but the failure mode and footprint differ enough that I'm filing a new report:

• #80760 reports a truncation to 24,000 chars of a context-engine projection in LCM/LCM-style setups.
• This report shows the Codex app-server runtime receiving a bare user string with no rendered context block at all, on a plain Telegram DM with no context-engine plugin.

Environment

• OpenClaw: 2026.5.22 (a374c3a)
• Runtime path: native Codex app-server (openai-codex/gpt-5.5)
• Trigger: user issued /model openai/gpt-5.5 from a Telegram DM session (Session-only model selection; runtime unchanged.)
• No LCM / Lossless Claw / external context-engine plugin
• Channel: Telegram DM
• Session keys involved:
  • Main Telegram DM session: 234d8e14-… (Anthropic / claude-opus-4-6)
  • Codex app-server session: 1907b7bf-… (openai-codex / gpt-5.5)

Symptom (real user trace)

A 4-minute, 3-message Telegram exchange about the "Claude Sonnet 4.8" leak (including two screenshots) was followed by the user asking, in the same DM, in the same session:

David Ondrej是谁，此前消息是否可靠 ("who is David Ondrej and is the prior message trustworthy?")

The gpt-5.5 answer completely ignored the immediately preceding Sonnet-4.8 thread and drifted onto an unrelated OpenAI/Codex OAuth topic — clearly anchoring on something other than the actual prior turns. The user reasonably interpreted this as "the model lost context".

Evidence from on-disk session logs

Two findings:

1. Two parallel session jsonl files exist for the same Telegram DM.

   • The Anthropic main session continues to be written to one file (234d8e14-…jsonl).
   • All gpt-5.5 turns are written to a separate session jsonl (1907b7bf-…jsonl) tagged with idempotencyKey: codex-app-server:…:prompt.
   • The main session file shows no assistant entries at all between 15:21 and 18:17 (the entire gpt-5.5 window), even though many user turns and assistant responses occurred in Telegram during that period.

2. The user message stored in the Codex app-server session is a bare string with no conversation context block. Example (verbatim, no redaction needed):

   {
     "type": "message",
     "id": "4bd26b6d-…",
     "timestamp": "2026-05-25T10:08:16.592Z",
     "message": {
       "role": "user",
       "content": "David Ondrej是谁，此前消息是否可靠",
       "idempotencyKey": "codex-app-server:…:prompt"
     }
   }

   For the same Telegram DM, when answered by the Anthropic main runtime instead, user content includes a full Conversation info (untrusted metadata) / Sender / Conversation context (untrusted, chronological, selected for current message) block plus image parts.

In other words, in this Telegram-DM-only repro the model isn't seeing a truncated-to-24k projection — it's seeing only the bare current user prompt, with no rendered context block at all (or one that resolves to empty). So one of these is happening:

• The projection cap in projectContextEngineAssemblyForCodex(...) is being applied before anything from the Telegram conversation history reaches it, or
• For sessions without an external context-engine plugin, the Codex app-server route is not assembling any Telegram conversation context in the first place, so the projection step has nothing to project.

Either way the user-visible behavior is identical to #80760: the model talks confidently while missing all but the current prompt, and there is no UI signal.

Why this matters

• This is reproducible with no plugins installed beyond a stock OpenClaw + Telegram + OpenAI Codex OAuth setup, which is a very common configuration.
• Any user who issues /model openai/gpt-5.5 (or another codex-app-server-runtime model) for a single turn ends up silently throwing away the rest of the chat for that turn.
• Telegram users in particular won't see any indication; the gpt-5.5 reply looks normal but is effectively a fresh single-turn call.
• This makes /model to non-Anthropic models effectively unsafe for any conversational use, even for very short follow-ups.

Reproduction shape

1. Stock OpenClaw 2026.5.x. No LCM / context-engine plugins.
2. Telegram DM session with Anthropic as the default model.
3. Have a few turns of normal conversation (text + images), enough that current context contains meaningful prior turns.
4. Run /model openai/gpt-5.5 (any codex-app-server-runtime model triggers the same path).
5. Ask a follow-up question that uses indexical references like "the previous message", "is it trustworthy", "what did we just discuss".
6. Inspect ~/.openclaw/agents/<agent>/sessions/<codex-session>.jsonl — the user message will be stored as a bare string with no conversation context.

Suggestions

In addition to the budget-aware projection cap fix already proposed in #80760, it would help a lot if:

1. The Codex app-server runtime emitted a clear diagnostic / trajectory event whenever the projected/rendered context for a turn is 0 (or below some sane floor) while the source session has prior turns.
2. When /model switches a Telegram (or any chat-channel) session to a codex-app-server-runtime model, the runtime should still receive the OpenClaw-side "Conversation context" block, not just the bare current user prompt.
3. The model-side prompt for a codex-app-server turn should at minimum carry sender metadata + the last N turns / current chat context block, mirroring what the Anthropic main runtime gets.

Happy to share the two session jsonl excerpts (with PII removed) if helpful for repro.