openclaw - ✅(Solved) Fix [Bug]: Telegram /models success is session-scoped but reset/restart silently falls back to stale agent default [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75965Fetched 2026-05-03 04:43:46
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
2
Author
Timeline (top)
commented ×2closed ×1cross-referenced ×1unsubscribed ×1

In a Telegram group bound to a non-main agent, /models (or model switch command) reports success, e.g. Model changed to ollama/gemma4:31b, and the current session can indeed use that model. However, after session reset/recreation or gateway restart, the chat silently falls back to the agent's persistent default from openclaw.json.

If that persistent default is stale or invalid, the bot stops replying with provider errors such as Ollama 404 model 'gemma4' not found.

The confusing part is that the Telegram UI says only Model changed to ... without making it clear that this is a session-scoped override, not the agent's durable default. In production group-bot usage this looks like OpenClaw randomly changed/reverted the model.

Error Message

[agent/embedded] embedded run agent end ... model=gemma4 provider=ollama error=404 {"error":"model 'gemma4' not found"} [diagnostic] lane task error: lane=session:agent:uubot:telegram:group:... error="FailoverError: 404 {"error":"model 'gemma4' not found"}" Embedded agent failed before reply: 404 {"error":"model 'gemma4' not found"}

Root Cause

In a Telegram group bound to a non-main agent, /models (or model switch command) reports success, e.g. Model changed to ollama/gemma4:31b, and the current session can indeed use that model. However, after session reset/recreation or gateway restart, the chat silently falls back to the agent's persistent default from openclaw.json.

If that persistent default is stale or invalid, the bot stops replying with provider errors such as Ollama 404 model 'gemma4' not found.

The confusing part is that the Telegram UI says only Model changed to ... without making it clear that this is a session-scoped override, not the agent's durable default. In production group-bot usage this looks like OpenClaw randomly changed/reverted the model.

Fix Action

Fixed

PR fix notes

PR #75980: fix(model): clarify session-scoped model switches

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2-5 bullets:

  • Problem: /model acknowledged a model switch without saying the override is scoped to the current session.
  • Why it matters: users can mistake the acknowledgement for a durable agent default change, then get surprised after a reset or restart.
  • What changed: model switch acknowledgements now say for this session when setting a non-default model.
  • What did NOT change (scope boundary): this does not change persistence semantics, model selection logic, or default reset wording.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #75965
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: the acknowledgement text did not describe the existing session-scoped behavior.
  • Missing detection / guardrail: model directive tests checked that the success message existed, but not that it communicated the scope.
  • Contributing context (if known): N/A

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/auto-reply/reply/directive-handling.model.test.ts
  • Scenario the test should lock in: /model openai/gpt-4o reports that the model is set for this session.
  • Why this is the smallest reliable guardrail: the affected behavior is the directive acknowledgement string.
  • Existing test that already covers this (if any): model directive persistence tests already covered successful switching.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

/model acknowledgements for non-default selections now say the switch applies to this session.

Diagram (if applicable)

Before:
/user sends /model openai/gpt-4o -> "Model set to openai/gpt-4o."

After:
/user sends /model openai/gpt-4o -> "Model set to openai/gpt-4o for this session."

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: Linux
  • Runtime/container: local repo test runner
  • Model/provider: N/A
  • Integration/channel (if any): text command acknowledgement
  • Relevant config (redacted): N/A

Steps

  1. Send /model openai/gpt-4o in a session where that model is allowed.
  2. Read the acknowledgement text.

Expected

  • The acknowledgement makes clear the switch applies to this session.

Actual

  • Before this PR, the acknowledgement did not state the scope.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

pnpm test src/auto-reply/reply/directive-handling.model.test.ts

Result: 47 tests passed.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: model directive success acknowledgement includes for this session, alias acknowledgement includes the same scope text, and the targeted test file passes.
  • Edge cases checked: default reset wording is unchanged.
  • What you did not verify: live Telegram group behavior.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: acknowledgement text changes can affect brittle tests or docs that assert the exact sentence.
    • Mitigation: updated the targeted unit tests for the new user-facing wording.

Changed files

  • src/auto-reply/reply/directive-handling.impl.ts (modified, +1/-1)
  • src/auto-reply/reply/directive-handling.model.test.ts (modified, +4/-1)
  • src/auto-reply/reply/get-reply-directives-apply.ts (modified, +1/-1)

Code Example

{
  "id": "uubot",
  "model": "ollama/gemma4"
}

---

Model changed to ollama/gemma4:31b
This model will be used for your next message.

---

[agent/embedded] embedded run agent end ... model=gemma4 provider=ollama error=404 {"error":"model 'gemma4' not found"}
[diagnostic] lane task error: lane=session:agent:uubot:telegram:group:... error="FailoverError: 404 {\"error\":\"model 'gemma4' not found\"}"
Embedded agent failed before reply: 404 {"error":"model 'gemma4' not found"}

---

Session model changed to ollama/gemma4:31b. This does not change the agent's persistent default; /reset or a new session may fall back to openclaw.json.

---

[Use for this session] [Set as uubot default]

---

Session reset. Model reverted from ollama/gemma4:31b to agent default ollama/gemma4.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior / UX bug around model state persistence

Summary

In a Telegram group bound to a non-main agent, /models (or model switch command) reports success, e.g. Model changed to ollama/gemma4:31b, and the current session can indeed use that model. However, after session reset/recreation or gateway restart, the chat silently falls back to the agent's persistent default from openclaw.json.

If that persistent default is stale or invalid, the bot stops replying with provider errors such as Ollama 404 model 'gemma4' not found.

The confusing part is that the Telegram UI says only Model changed to ... without making it clear that this is a session-scoped override, not the agent's durable default. In production group-bot usage this looks like OpenClaw randomly changed/reverted the model.

Concrete observed case

  • Agent: uubot
  • Channel: Telegram group
  • Runtime OpenClaw version: 2026.4.29
  • Local Ollama models include gemma4:31b
  • Persistent agent config accidentally had:
{
  "id": "uubot",
  "model": "ollama/gemma4"
}
  • Telegram /models interaction reported success:
Model changed to ollama/gemma4:31b
This model will be used for your next message.
  • The current session then worked and status showed the session model as gemma4:31b.
  • Later, after session reset/recreation/restart behavior, UUBOT stopped replying.
  • Gateway logs showed repeated failures:
[agent/embedded] embedded run agent end ... model=gemma4 provider=ollama error=404 {"error":"model 'gemma4' not found"}
[diagnostic] lane task error: lane=session:agent:uubot:telegram:group:... error="FailoverError: 404 {\"error\":\"model 'gemma4' not found\"}"
Embedded agent failed before reply: 404 {"error":"model 'gemma4' not found"}

Why this is a problem

There are two separate model states:

  1. session-scoped model override, changed by /models
  2. durable agent default in openclaw.json

The UI confirmation does not clearly communicate the scope. A user sees "Model changed to X" and reasonably expects the bot/agent to keep using X, especially in a group bot context.

When the session is recreated or reset, OpenClaw silently falls back to the durable default. If the durable default differs from the session override, the behavior appears to randomly revert. If the durable default is invalid, the bot stops replying entirely.

Expected behavior

One of these would be much safer:

  1. The /models confirmation should explicitly say it is session-only, for example:
Session model changed to ollama/gemma4:31b. This does not change the agent's persistent default; /reset or a new session may fall back to openclaw.json.
  1. Provide a clear command/button to persist the selected model as the current agent's durable default, e.g.:
[Use for this session] [Set as uubot default]
  1. On reset/new session, if a previous session override differs from the agent default, show a clear notice:
Session reset. Model reverted from ollama/gemma4:31b to agent default ollama/gemma4.
  1. If the agent default model is invalid/unavailable, surface an explicit channel-visible diagnostic instead of silently failing before reply.

Related issues

This seems related to the broader model state / override confusion already discussed in:

  • #28965 — Simplify Model Configuration: Single-Source Reconcile + Session Override Reset
  • #51251 — Session modelOverride persists across gateway restarts, silently overrides config default
  • #62587 — /new or /reset does not clear session-level authProfileOverride and modelOverride between sessions
  • #63178 — Per-session /model override lost after compaction/fallback
  • #68472 — explicit-session turns lose session model overrides before next turn
  • #75405 — Telegram group slash commands with non-main agents

Suggested classification

This is not just a documentation issue. The current wording and reset behavior create a production footgun for Telegram group agents: the system says the model changed, but the durable agent configuration remains unchanged and can later override the working session state without a visible explanation.

extent analysis

TL;DR

To fix the issue, the /models confirmation should explicitly indicate that the model change is session-only and provide a clear way to persist the selected model as the agent's durable default.

Guidance

  • The current implementation of the /models command only changes the session-scoped model override, but the UI confirmation does not clearly communicate this scope.
  • To mitigate the issue, consider adding a clear notice when the session is reset or recreated, indicating that the model has reverted to the agent's default.
  • Provide a clear command or button to persist the selected model as the current agent's durable default.
  • Consider surfacing an explicit channel-visible diagnostic when the agent default model is invalid or unavailable.

Example

A possible implementation of the revised /models confirmation could be:

Session model changed to ollama/gemma4:31b. This does not change the agent's persistent default; /reset or a new session may fall back to openclaw.json.

Alternatively, a clear command or button to persist the selected model as the current agent's durable default could be added:

[Use for this session] [Set as uubot default]

Notes

The issue is related to the broader model state and override confusion discussed in several other issues, including #28965, #51251, and #63178.

Recommendation

Apply a workaround by revising the /models confirmation to explicitly indicate the scope of the model change and provide a clear way to persist the selected model as the agent's durable default, as this will help prevent production issues with Telegram group agents.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

One of these would be much safer:

  1. The /models confirmation should explicitly say it is session-only, for example:
Session model changed to ollama/gemma4:31b. This does not change the agent's persistent default; /reset or a new session may fall back to openclaw.json.
  1. Provide a clear command/button to persist the selected model as the current agent's durable default, e.g.:
[Use for this session] [Set as uubot default]
  1. On reset/new session, if a previous session override differs from the agent default, show a clear notice:
Session reset. Model reverted from ollama/gemma4:31b to agent default ollama/gemma4.
  1. If the agent default model is invalid/unavailable, surface an explicit channel-visible diagnostic instead of silently failing before reply.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Telegram /models success is session-scoped but reset/restart silently falls back to stale agent default [1 pull requests, 2 comments, 3 participants]