#model corrupts openclaw.json

21 messages · Page 1 of 1 (latest)

minor ruin
#

With a single OpenClaw instance, how to recover if the model breaks  openclaw.json ? Any fully automated, no-human-in-the-loop fixes?

#

krill help me

wise brambleBOT
#

Let me check the docs and source so I don’t make up config behavior.

#

Short version: yes for a couple of cases, but not a fully generic self-healer yet.

What exists now:

  • config writes use temp-file + replace, and keep backup rotation (openclaw.json.bak, .bak.1 ... .bak.4)
  • openclaw doctor --fix also writes a backup and repairs some config issues
  • there is a targeted auto-restore for the known “config got clobbered down to just update.channel” case, it restores from .bak and saves the bad file as openclaw.json.clobbered.<timestamp>

What does not exist today:

  • arbitrary “model mangled openclaw.json in some random way, recover everything automatically” recovery
  • with a single instance, once config is invalid, the Gateway does not fully boot, so you’re down to diagnostics/doctor, not normal agent behavior

So for truly no-human recovery on one box, I’d recommend:

  1. keep openclaw.json mostly static
  2. put model-managed bits in a separate $include file
  3. only mutate via openclaw config set or config.patch, not full-file config.apply
  4. add an out-of-band watchdog, systemd/cron/launcher, that validates and restores last good .bak if load fails
minor ruin
#

config.patch？what is this？

wise brambleBOT
#

config.patch is the partial-update config API.

Think of it like this:

  • config.apply = replace the whole openclaw.json
  • config.patch = change only the bits you send

Semantics:

  • objects merge recursively
  • null deletes a key
  • arrays replace the whole array

Example:

Current config:

# 
{
  gateway: { mode: "local", port: 18789 },
  channels: { telegram: { enabled: true } }
}

Patch:

{ gateway: { port: 18888 } }

Result:

{
  gateway: { mode: "local", port: 18888 },
# 
  channels: { telegram: { enabled: true } }
}

So it is much safer than config.apply if you only want to tweak one section.

Important bit:

  • it is mainly a Gateway RPC / API method
  • from shell, if you just want one simple change, openclaw config set ... is usually easier
  • if a tool/UI/agent is doing programmatic edits, config.patch is the safer choice

Typical RPC flow:

  1. config.get to fetch current config + hash
  2. config.patch with your partial object + that baseHash

Docs: https://docs.openclaw.ai/gateway/configuration

#

If you want, I can show the exact same change done with:

  • config.patch
  • openclaw config set

side by side.

minor ruin
#

how to use config.patch？

wise brambleBOT
#

config.patch is a Gateway RPC, so the usual flow is:

  1. get the current config hash
  2. send a partial patch with that hash

Example, change just gateway.port:

openclaw gateway call config.get --params '{}'

Take the returned hash, then:

openclaw gateway call config.patch --params '{
  "raw": "{ gateway: { port: 18888 } }",
# 
  "baseHash": "<paste-hash-here>"
}'

What it does:

  • merges objects
  • null deletes keys
  • arrays are fully replaced

Examples:

Set a nested field:

openclaw gateway call config.patch --params '{
  "raw": "{ channels: { telegram: { enabled: true } } }",
# 
  "baseHash": "<hash>"
}'

Delete a section:

openclaw gateway call config.patch --params '{
  "raw": "{ channels: { telegram: null } }",
  "baseHash": "<hash>"
}'

Important:

  • baseHash matters, it prevents overwriting someone else’s newer config
  • this is safer than config.apply, because it does not replace the whole file
#

If you are just changing one key from shell, this is usually easier:

openclaw config set gateway.port 18888

So, practical rule:

  • one key → openclaw config set
  • partial programmatic update → config.patch
  • full replacement → config.apply

Docs: https://docs.openclaw.ai/gateway/configuration

If you want, I can give you a ready-made config.patch example for your exact change.

minor ruin
#

how to use and what this command can do : openclaw gateway call

wise brambleBOT
#

Let me check the CLI docs so I give you the right shape.

#

openclaw gateway call is the low-level RPC client for a running Gateway.

Think of it as:

“send one raw RPC method call to the Gateway, with JSON params”

What it can do

Anything the Gateway exposes as an RPC method, for example:

  • status
  • health
  • config.get
  • config.patch
  • logs.tail

So yes, it can do powerful stuff, including config reads/writes, but only through defined Gateway methods. It is not a generic shell runner.

#

Basic shape

openclaw gateway call <method> --params '<json>'

Examples:

openclaw gateway call status
openclaw gateway call health
openclaw gateway call logs.tail --params '{"sinceMs":60000}'
openclaw gateway call config.get --params '{}'

Important flags

#
  • --params <json> JSON object string, default is {}
  • --json machine-readable output
  • --url <url> target a specific gateway
  • --token / --password auth
  • --timeout <ms>
  • --expect-final for methods that stream intermediate events first

Important gotcha

--params must be valid JSON, not JSON5.

So this is valid:

--params '{"sinceMs":60000}'
#

This is not:

--params '{sinceMs:60000}'

When to use it

Good for:

  • scripting
  • debugging
  • calling RPC methods that don’t have a nicer CLI wrapper yet

Usually easier alternatives exist for normal tasks:

  • config key edits → openclaw config set
  • health/status → openclaw status, openclaw gateway status
  • repairs → openclaw doctor