My agent has issues updating OpenClaw configuration. every time they change something the gateway is reverting back to the last backup made. the only way to do it is shutdown gateway. but then my agent stop working and I need correct the file manually and start the gateway manually. Any way to have it work like before, when the gateway did not revert back the config files?
#Gateway reverting changes made by my agent(s).
tacit frigate
steep waspBOT
plucky shardBOT
This usually means the Gateway is rejecting the new config and restoring the last-known-good copy. It’s intentional protection, not the old “just accept any file write” behavior.
First, can you share:
openclaw --version
Then check what got rejected:
openclaw logs --follow
CONFIG="$(openclaw config file)"
ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | head
openclaw config validate
openclaw doctor
Common cause: the agent is using config.apply with a partial config. config.apply replaces the entire config, so if it only sends the changed section, OpenClaw sees the rest as deleted and restores the backup. Prefer:
openclaw config set some.path 'value' --strict-json
or, from an agent/tool flow, use config.patch for partial edits instead of config.apply.
You can disable watching with gateway.reload.mode: "off", but I wouldn’t recommend it as the fix — then changes only apply after restart, which is basically the manual workflow you’re trying to avoid.
Docs:
https://docs.openclaw.ai/gateway/configuration#config-hot-reload
https://docs.openclaw.ai/gateway/troubleshooting#gateway-restored-last-known-good-config
tacit frigate
I am on version 2024-04-23, issue started after updating to v24 and needing to downgrade to 23 again.
plucky shardBOT
Assuming you mean 2026.4.23 / 2026.4.24 — yep, that sounds like either:
- the agent is still writing an invalid/partial config, or
- v24 left you with a bad/rejected config cycle and .23 is now restoring last-known-good.
Important bit: config.apply is full config replacement only. If the agent sends just the changed section, OpenClaw will treat the rest as deleted and restore backup. Use config.patch or openclaw config set instead. Docs call this out here: (docs.openclaw.ai)
Please run/paste:
openclaw --version
openclaw gateway status
CONFIG="$(openclaw config file)"
ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | head
openclaw config validate --json
openclaw doctor
Also check logs for the exact rejection reason:
openclaw logs --follow
Look for Config write rejected, last-known-good, .clobbered, or .rejected.
Quick workaround: tell the agent not to edit ~/.openclaw/openclaw.json directly and not to use config.apply unless it is sending the full config. For small changes, use:
openclaw config set some.path 'value' --strict-json
If this started specifically after 2026.4.24, it’s worth filing a GitHub issue with the .rejected.* / .clobbered.* diff and the validation output. 2026.4.24 had a lot of plugin/model infrastructure changes, so a regression is plausible.
tacit frigate
I restored version .23, so I do not have version . 24 to capture the logs propperly... I do find it strange that even restore did not fix issue.
plucky shardBOT
Yeah, that actually makes sense: downgrading the package won’t necessarily clear this, because the config + recovery state live in ~/.openclaw, and the agent may still be repeating the same bad write.
You don’t need v24 logs — trigger one failed config change on .23, then grab the current reason:
openclaw --version
CONFIG="$(openclaw config file)"
ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | head
openclaw config validate --json
openclaw logs --tail 200 | grep -Ei "last-known-good|clobbered|rejected|invalid config|Config write"
If there’s a .rejected.*, the agent/tool write was rejected before commit.
If there’s a .clobbered.*, something edited the file directly and Gateway restored it.
Most likely fix: update the agent instruction to never use config.apply for partial changes and not edit openclaw.json directly. Use openclaw config set or config.patch.