openclaw - 💡(How to fix) Fix [Bug]: Telegram topic /status can report fallback model from internal subagent announce as the session model

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In a Telegram forum topic, /status and activity UI can show google/gemini-2.5-flash as the topic session model after an internal subagent announce/recovery turn used fallback, even though the normal user-facing topic session is configured for and returns to openai-codex/gpt-5.5.

Steps to reproduce

1. Run OpenClaw 2026.5.19 with a Telegram forum topic bound to a main agent whose primary model is openai-codex/gpt-5.5 and whose fallback includes google/gemini-2.5-flash.
2. From that Telegram topic, spawn a Codex subagent.
3. Have one subagent or parent announce/recovery turn hit a Codex app-server timeout, causing fallback to google/gemini-2.5-flash.
4. Run /status in the Telegram topic or inspect the topic activity UI.
5. Observe the status/activity display can make the topic look like it is now using Gemini, although the next ordinary user turn uses openai-codex/gpt-5.5 again.

Observed topic/session:

• session key: agent:main:telegram:group:-1003871627242:topic:6823
• successful child: agent:codex:subagent:f1cc437f-6a10-4b48-a3da-2d67f47d747c
• timed-out child: agent:codex:subagent:c34fca91-3b85-4c8a-a926-07cafbe162c2

Expected behavior

/status should distinguish at least these concepts instead of presenting them as one ambiguous session model:

• configured/current primary model for the user-facing Telegram topic;
• configured fallback chain;
• last actual model used for the most recent user-facing turn;
• last actual model used by an internal subagent announce/recovery turn.

If an internal announce turn uses a fallback model, that should not make the topic status look like the user-facing session has permanently switched to that fallback.

Actual behavior

After an internal subagent announce/recovery turn used Gemini fallback, the topic activity UI showed a Gemini-labelled assistant message, and /status output around the same period showed fallback-token/accounting state that matched that internal Gemini run.

The confusing user-visible effect was: the operator saw Gemini in the topic and asked why the Codex/OpenAI workflow was using Gemini, even though the successful Codex subagent had not run on Gemini and the next normal topic turn returned to OpenAI/Codex.

OpenClaw version

2026.5.19

CLI on host reported:

OpenClaw 2026.5.19 (a185ca2)

The Telegram /status card in the repro reported:

OpenClaw 2026.5.19 (0e30120)

Operating system

Ubuntu 24.04.3 LTS aarch64

Install method

npm global, single system install:

/usr/bin/openclaw -> /usr/lib/node_modules/openclaw/openclaw.mjs
ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

Model

Primary: openai-codex/gpt-5.5 / openai/gpt-5.5

Fallback: google/gemini-2.5-flash

Provider / routing chain

OpenClaw -> OpenAI Codex runtime, with Google Gemini fallback configured

Additional provider/model setup details

The same Telegram topic continued to work with OpenAI/Codex after the fallback event.

A later /status tool result for the same session reported:

Model: openai-codex/gpt-5.5
Fallbacks: google/gemini-2.5-flash
Session: agent:main:telegram:group:-1003871627242:topic:6823
Execution: direct · Runtime: OpenAI Codex

So this is not a permanent model switch or an OpenAI outage. The confusing state appears to be caused by fallback usage from an internal announce/recovery turn being surfaced as topic/session model state.

Logs, screenshots, and evidence

Gateway logs show the main Telegram topic turn timed out on Codex and then fell back to Gemini:

2026-05-21T19:18:26.461+00:00 [agent/embedded] codex app-server turn idle timed out waiting for completion
2026-05-21T19:18:26.534+00:00 [agent/embedded] embedded run failover decision: runId=e9a3b0a4-edef-4ff6-a201-3d860cad8ddc stage=assistant decision=fallback_model reason=timeout from=openai-codex/gpt-5.5 rawError=codex app-server attempt timed out
2026-05-21T19:18:26.551+00:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=timeout next=google/gemini-2.5-flash detail=codex app-server attempt timed out
2026-05-21T19:18:54.128+00:00 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=openai/gpt-5.5 candidate=google/gemini-2.5-flash reason=unknown next=none

Trajectory for the Telegram topic shows the same run first failing on Codex and then succeeding on Gemini:

{"ts":"2026-05-21T19:18:26.463Z","type":"model.completed","runId":"e9a3b0a4-edef-4ff6-a201-3d860cad8ddc","provider":"openai-codex","modelId":"gpt-5.5","timedOut":true}
{"ts":"2026-05-21T19:18:28.649Z","type":"session.started","runId":"e9a3b0a4-edef-4ff6-a201-3d860cad8ddc","provider":"google","modelId":"gemini-2.5-flash"}
{"ts":"2026-05-21T19:18:54.036Z","type":"model.completed","runId":"e9a3b0a4-edef-4ff6-a201-3d860cad8ddc","provider":"google","modelId":"gemini-2.5-flash","timedOut":false,"usage":{"input":120190,"output":3507,"total":123697}}

Task state showed the successful Milestone 1 child was a separate Codex subagent and delivered successfully:

{
  "runtime": "subagent",
  "sourceId": "de593004-fad4-4daf-8652-cfe1a51b1c31",
  "requesterSessionKey": "agent:main:telegram:group:-1003871627242:topic:6823",
  "childSessionKey": "agent:codex:subagent:f1cc437f-6a10-4b48-a3da-2d67f47d747c",
  "status": "succeeded",
  "deliveryStatus": "delivered"
}

A different child later timed out:

{
  "runtime": "subagent",
  "sourceId": "4d379e8f-a2a4-40d3-a2de-5f5dac5fb2cf",
  "requesterSessionKey": "agent:main:telegram:group:-1003871627242:topic:6823",
  "childSessionKey": "agent:codex:subagent:c34fca91-3b85-4c8a-a926-07cafbe162c2",
  "status": "timed_out",
  "deliveryStatus": "delivered"
}

The internal announce for that timed-out child used Gemini:

{"ts":"2026-05-21T19:34:29.374Z","type":"session.started","runId":"announce:v1:agent:codex:subagent:c34fca91-3b85-4c8a-a926-07cafbe162c2:4d379e8f-a2a4-40d3-a2de-5f5dac5fb2cf","provider":"google","modelId":"gemini-2.5-flash"}
{"ts":"2026-05-21T19:34:31.742Z","type":"model.completed","provider":"google","modelId":"gemini-2.5-flash","usage":{"input":39908,"output":122,"total":40030},"assistantTexts":["The latest notification is another timed-out subagent that didn't produce any output..."]}

That ~40k in / 122 out usage matched the confusing /status/activity observation from the topic.

A later normal user-facing turn on the same topic used OpenAI/Codex again:

{"ts":"2026-05-21T19:38:39.563Z","type":"session.started","runId":"912c97c8-e7ad-45fc-9751-a99aedd13c6d","provider":"openai-codex","modelId":"gpt-5.5"}
{"ts":"2026-05-21T19:38:48.310Z","type":"tool.result","runId":"912c97c8-e7ad-45fc-9751-a99aedd13c6d","provider":"openai-codex","modelId":"gpt-5.5","tool":"session_status"}
{"ts":"2026-05-21T19:38:58.716Z","type":"model.completed","runId":"912c97c8-e7ad-45fc-9751-a99aedd13c6d","provider":"openai-codex","modelId":"gpt-5.5","timedOut":false}

Impact and severity

Affected: Telegram forum-topic sessions with fallback models configured, especially where subagent completion/timeout announce turns run in the parent topic session.

Severity: Medium. The underlying work may still complete, but operator visibility is misleading: /status and activity can make it look like the topic or Codex worker switched to Gemini when only an internal announce/recovery turn used fallback.

Frequency: observed once on a live 2026.5.19 VPS during subagent work. NOT_ENOUGH_INFO on whether every internal announce fallback reproduces the misleading status display.

Consequence: debugging confusion, false suspicion that the wrong model is serving the user-facing topic, and difficulty separating subagent/announce model use from normal topic model use.

Additional information

Related but not a duplicate:

• #85070 is also about Telegram forum-topic subagent completion, but that bug is delivery-specific: the announce agent failed because it did not call the message tool. This issue is status/model attribution after fallback/internal announce turns. They are adjacent surfaces, but do not appear to require the same fix.
• #51441 requests resolved backend/fallback fields in session_status; this issue is a concrete Telegram/subagent-announce reproduction showing why the current status output is ambiguous.
• #64902 is related fallback observability/audit trail work.

Likely investigation surfaces:

• session_status tool/model usage reporting
• session usage persistence fields used by status/activity UI
• subagent announce/recovery turns and whether their model usage should update the parent topic's user-facing session model state

I plan to pick this up and open a PR for the fix, assuming maintainers agree with this issue scope.