Bug type

Behavior bug (incorrect output/state without crash)

Summary

When agents.defaults.models is modified in openclaw.json (e.g. removing a model from the allowlist), the gateway detects the config change but does not apply it at runtime. The stale model list keeps being served to clients (e.g. /models on Telegram).

Steps to reproduce

1. Have a model (e.g. openrouter/minimax/minimax-m2.5) in agents.defaults.models
2. Remove it from the config file
3. Observe the gateway log:

   config change detected; evaluating reload (agents.defaults.models.openrouter/minimax/minimax-m2.5 ...)
   config hot reload applied (agents.defaults.heartbeat)
   

4. Send /models on Telegram — the removed model still appears
5. Send /reset on Telegram — the session may pick up the removed model as active

Expected behavior

• Removing a model from agents.defaults.models should take effect immediately (or at least on gateway restart)
• /reset should never select a model that is no longer in the allowlist

Actual behavior

• Hot-reload detects the change but only applies heartbeat and a few other fields — agents.defaults.models is silently skipped
• Even after a full gateway restart, a model stored in sessions.json (from a previous /model selection) can be restored by /reset, bypassing the allowlist entirely

OpenClaw version

2026.3.2

Operating system

Ubuntu 22.04 LTS

Install method

npm global

Logs, screenshots, and evidence

Impact and severity

• Affected: Any user who removes a model from agents.defaults.models via config edit; particularly visible on Telegram (and likely any channel with /models and /reset commands)
• Severity: Annoying to workflow-blocking — the unwanted model keeps being selected even after explicit removal, requiring manual intervention in internal JSON files to fix
• Frequency: Always reproducible — every /reset after removing a model from the allowlist will restore the stale model until sessions.json is manually patched
• Consequence: User is silently served a model they explicitly don't want, with no error or warning. The only indication is noticing degraded response quality or checking /model. Recovery requires knowing to manually edit sessions.json, which is not documented anywhere.

Additional information

Workaround

1. Remove model from agents.defaults.models in config
2. Manually clear model, modelOverride, and modelProvider from all affected session entries in ~/.openclaw/agents/main/sessions/sessions.json
3. Restart gateway

Suggestion

• Make agents.defaults.models hot-reloadable, OR clearly document it requires a restart
• On /reset, validate the stored session model against the current allowlist before using it