Version

OpenClaw 2026.5.7 (eeef486)

Summary

openclaw config set on agents.list[N].model.* paths emits an identical Restart the gateway to apply. warning regardless of whether the target agent currently has an agentRuntime override. The warning is misleading for active agents (no agentRuntime field) — these agents config-hot-load on next invocation and never need a restart. The warning is correct for dormant agents with agentRuntime.id=codex overrides, which cache runtime plan eagerly and do require a gateway restart to load new model state.

Reproduction

Setup: an agent with no agentRuntime field (active agent), e.g., mason-vale at agents.list[3]:

$ openclaw config get "agents.list[3].agentRuntime" 2>&1 | tail -1
(undefined - field absent)

$ openclaw config get "agents.list[3].model.primary"
ollama/qwen3-coder-next

$ openclaw config set "agents.list[3].model.primary" '"ollama/kimi-k2.6"' --strict-json
Updated agents.list[3].model.primary
Restart the gateway to apply.

$ openclaw config get "agents.list[3].model.primary"
ollama/kimi-k2.6

Now invoke the agent IMMEDIATELY without restarting:

$ openclaw agent --agent mason-vale --message "what model are you running" --json
{
  "model": "kimi-k2.6",
  "provider": "ollama",
  "harness": "pi",
  "duration": 7565,
  "fallbackUsed": false,
  "status": "ok"
}

The agent responded on the new model (kimi-k2.6) without a gateway restart. The 7565ms response time is consistent with normal first-invocation latency, not stale runtime serving cached config.

For comparison, dormant agents with agentRuntime.id=codex override DO require a restart — the runtime plan is cached and not refreshed by lazy invocation.

Expected behaviour

config set should differentiate the warning based on the target agent's agentRuntime field:

• For agents with no agentRuntime field: omit the warning, or downgrade to "Config will apply on next invocation."
• For agents WITH agentRuntime field: keep the existing "Restart the gateway to apply." warning

Why this matters

The undifferentiated warning creates unnecessary operational pressure:

• Operators schedule restarts that aren't needed
• Multi-agent recovery batches budget a gateway restart for every batch (correct only if any agent in the batch is dormant)
• The signal-to-noise ratio of restart warnings drops, making the warning easier to ignore when it actually matters

Today's (2026-05-11) Mason model swap was applied via config set and the agent live-loaded the new state in 7565ms with zero downtime. By contrast, today's 18-dormant fleet recovery genuinely required a gateway restart for the runtime to converge with disk. The CLI emitted the same warning for both cases, providing no operational guidance.

Suggested fix

In the config set handler that emits the warning, check whether the target path begins with agents.list[N]. and if so, inspect agents.list[N].agentRuntime post-set:

• If agentRuntime is absent (or only contains non-load-bearing fields): suppress or rephrase the warning
• If agentRuntime.id is set: keep the existing warning

Alternative: add a --no-warn-restart flag for operators who know the target agent is active, allowing automation to suppress the warning unconditionally.

Related

• Sister filing: #80721 (config unset missing --dry-run parity)
• Doctor-damage recovery context: #79440 (post-doctor agentRuntime override left on 18 dormants, recovered via config set + config unset agentRuntime + gateway restart on 2026-05-11)