The OpenClaw 2026.4.5 gateway stripped unrecognized config fields on startup, wrote the stripped version back to disk, and failed to restore from backup because the restoredFromBackup flag was hardcoded to false — resulting in permanent, silent config destruction across the user fleet.
OpenClaw 2026.4.5 introduced a config-parsing change that rejected fields not declared in the schema. The intent was forward-compatibility: strip unknown keys so they don't confuse the runtime. The implementation, however, did three destructive things: (1) it parsed the config, (2) it re-serialized and wrote the stripped version back to disk, overwriting the user's original file, and (3) when a subsequent sanity check detected the mismatch, it attempted restore-from-backup but the code path always evaluated restoredFromBackup=false, so the recovery was a no-op. Users who had custom fields — for experimental features, for third-party plugins, for their own tooling — lost them silently and irrecoverably on first restart after upgrade.
The Actual Culprit
Parse-then-overwrite on a user config file, combined with a hardcoded constant (restoredFromBackup=false) that silently disabled the only recovery path.
Touching a user's config file is a two-way trust operation. Lossy rewrites need an explicit user confirmation, not a silent 'we thought it was safe'.
If your recovery path is always false because of a constant, your recovery path does not exist. Audit all flags that gate destructive operations.
Loading comments...