openclaw - 💡(How to fix) Fix config set "Restart the gateway to apply" warning is misleading for active agents without agentRuntime override

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…

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.

Error Message

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

Root Cause

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.

Fix Action

Fix / Workaround

  • 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

Code Example

$ 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

---

$ 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"
}
RAW_BUFFERClick to expand / collapse

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)

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING