Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Heartbeat does not honor the configured agents.defaults.heartbeat.model on its own, because when the heartbeat session’s persisted providerOverride and modelOverride are removed, the next heartbeat run resolves to the primary agent model instead.

Steps to reproduce

1. Set:
   • primary model = openai-codex/gpt-5.4
   • heartbeat model = ollama/gemma4:e4b
   • heartbeat session = agent:main:main:heartbeat
2. Remove providerOverride and modelOverride from the heartbeat session entry.
3. Trigger the next heartbeat run.
4. Inspect the heartbeat session model.

Expected behavior

With agents.defaults.heartbeat.model configured to ollama/gemma4:e4b for agent:main:main:heartbeat, the expected behavior is that heartbeat runs on ollama/gemma4:e4b from config alone, without requiring persisted session-level providerOverride or modelOverride fields.

Actual behavior

After removing the heartbeat session’s persisted providerOverride and modelOverride, the next observed heartbeat run resolved back to openai-codex/gpt-5.4 instead of the configured Ollama heartbeat model, and restoring those session override fields returned heartbeat to the intended local model.

OpenClaw version

2026.4.2 (d74a122)

Operating system

macOS 15.7.4 (24G517)

Install method

Global Node installation under /opt/homebrew/lib/node_modules/openclaw (CLI launched as openclaw from that install).

Model

Configured heartbeat model under test: ollama/gemma4:e4b Observed fallback model when session overrides were removed: openai-codex/gpt-5.4

Provider / routing chain

OpenClaw CLI -> local OpenClaw gateway (loopback, token auth) -> configured provider "ollama" for heartbeat -> local Ollama model "gemma4:e4b" Observed fallback path after removing session overrides: OpenClaw heartbeat -> primary agent model "openai-codex/gpt-5.4"

Additional provider/model setup details

• Primary agent model in config: openai-codex/gpt-5.4
  • Heartbeat config in ~/.openclaw/openclaw.json:
    • agents.defaults.heartbeat.model = "ollama/gemma4:e4b"
    • agents.defaults.heartbeat.session = "agent:main:main:heartbeat"
  • Repro condition:
    • remove providerOverride and modelOverride from the heartbeat session entry
    • trigger the next heartbeat run
  • Workaround:
    • persist providerOverride: "ollama" and modelOverride: "gemma4:e4b" on the heartbeat session
  • Same behavior was also reproduced with ollama/qwen3.5:4b, so it did not appear specific to Gemma

Logs, screenshots, and evidence

- Config validated on the tested install: openclaw config validate --json returned {"valid":true,"path":"/Users/neo/.openclaw/openclaw.json"}
  - Tested config shows:
      - .openclaw/openclaw.json:169 primary model openai-codex/gpt-5.4
      - .openclaw/openclaw.json:223 heartbeat model ollama/gemma4:e4b
      - .openclaw/openclaw.json:224 heartbeat session agent:main:main:heartbeat
  - Observed runtime behavior:
      - after removing the heartbeat session’s persisted overrides, the next heartbeat resolved to gpt-5.4
      - after restoring the override fields, heartbeat returned to the intended local Ollama model
  - Session state evidence is in:
      - .openclaw/agents/main/sessions/sessions.json

Impact and severity

Affected users/systems/channels: observed on this local OpenClaw install for the heartbeat session agent:main:main:heartbeat Severity: breaks intended heartbeat model selection unless sticky session state is preserved Frequency: reproducible in the tested scenario when providerOverride and modelOverride are removed Consequence: heartbeat runs on the primary agent model instead of the configured heartbeat model, so config alone is not a reliable source of truth

Additional information

• OpenClaw version tested: 2026.4.2 (d74a122)
  • OS: macOS 15.7.4 (24G517)
  • Install method: global Node installation under /opt/homebrew/lib/node_modules/openclaw
  • This does not appear model-specific; it was observed with both ollama/gemma4:e4b and ollama/qwen3.5:4b
  • The issue appears to be config/session precedence rather than an Ollama runtime failure, because restoring the persisted session override returns heartbeat to the intended model