openclaw - 💡(How to fix) Fix openclaw config set strips unrelated top-level fields (gateway block disappears, exit 78/CONFIG) [1 comments, 2 participants]

Bug: openclaw config set <key> strips unrelated top-level fields on every write

Summary

Calling openclaw config set <a.b.c> "<value>" reads ~/.openclaw/openclaw.json, applies the change, and writes it back through a schema-aware serializer that silently drops top-level fields it doesn't recognize for the path being written. Same behavior occurs inside openclaw plugins install. Practical effect: writing one branch of the config corrupts adjacent branches.

The most painful instance we hit: writing under channels.<channel>.accounts.… strips the entire gateway block (including gateway.mode). The next gateway start then bails with exit 78/CONFIG ("missing gateway.mode") and the systemd unit's RestartPreventExitStatus=78 correctly refuses to crashloop, leaving the gateway down until manually re-configured.

Versions

• openclaw: 2026.4.20 (also reproduces under 2026.4.15 and 2026.4.27)
• node: v22.22.2 via nvm
• platform: Ubuntu 24.04 LTS (linux/x86_64)

Repro

# 1. Start with a healthy config that has gateway.mode set
openclaw onboard --mode local                 # writes gateway.mode=local

cat ~/.openclaw/openclaw.json | jq .gateway
# → { "mode": "local" }

# 2. Make any unrelated config write — e.g. set a channel-account field:
openclaw config set 'channels.foo.accounts.alice.userId' '"@alice:example.com"'

# 3. The gateway block is now gone:
cat ~/.openclaw/openclaw.json | jq .gateway
# → null

# 4. Same with `openclaw plugins install`:
openclaw plugins install some-trusted-plugin --dangerously-force-unsafe-install
# → also strips gateway.mode

# 5. The next gateway start dies:
openclaw gateway restart
# → "Gateway start blocked: existing config is missing gateway.mode."
# → exit 78/CONFIG

Expected

openclaw config set foo.bar baz should only modify foo.bar. Other top-level keys (gateway, auth, agents, wizard, etc.) should round-trip untouched.

Actual

Every write rewrites the whole file through a schema-aware serializer that drops fields the schema doesn't list as valid for the path being written. The dropped fields are not logged anywhere user-visible — the only signal is the next start's exit-78 the user has to chase backwards.

Workarounds in client code (until this is fixed)

We've shipped two defensive snapshot+restore wrappers in our CLI/plugin (the badgerclaw-cli repo, see PR #17 and PR #19) — every shell-out to openclaw <cmd> that mutates openclaw.json snapshots the gateway block before the call and merges it back afterward. It's correct but ugly, and every adjacent caller now has to know about this trap.

Suggested fix shape

The schema-aware writer should treat unknown top-level keys as opaque and pass them through. Stripping should be opt-in (e.g. via openclaw config set --strict) rather than the default.

If the fields really are unrecognised because the schema is incomplete, please at minimum:

1. Log a warning when the writer drops a field, naming the field and where it was last set.
2. Make the warning fatal under a flag so CI/automation surfaces this rather than silently hitting exit 78 at runtime.

Happy to test a fix branch on a real VPS if useful.