Blog

openclaw.json.clobbered and .rejected: why your OpenClaw config was overwritten

A file named openclaw.json.clobbered.<timestamp> beside your config is a payload OpenClaw set aside instead of leaving in place — the evidence of a replacement, not the cause of one. Before you touch anything, read the suffix, because the two OpenClaw writes there mean opposite things: .rejected means the write never landed and your active config was left alone, while .clobbered means the active config was replaced or repaired and the old payload was preserved for you. One is the safety net working; the other is the receipt for something you have already lost.

What you'll see
# in ~/.openclaw/, beside the active config:
openclaw.json
openclaw.json.clobbered.2026-04-10T14-28-24-105Z
openclaw.json.rejected.2026-04-10T14-28-24-105Z
openclaw.json.bak

# and, when the gateway's guard caught the write, a log line naming
# exactly which heuristics tripped:
previousBytes: 3641, nextBytes: 423 (severe size drop),
suspicious: ["size-drop:3641->423", "gateway-mode-removed"]

Log line and filename as reported in openclaw#64419 (2026-04-10, OpenClaw 2026.4.9).

.clobbered or .rejected — which one do you have?

This is the whole diagnosis, and it takes one ls. The OpenClaw troubleshooting docs treat the two suffixes as two separate signals:

You found What actually happened Did you lose anything?
openclaw.json.rejected.* An OpenClaw-owned config write "failed schema or clobber checks before commit" — the guard blocked it and the active config was never modified No. The rejected payload is saved "for inspection". Read it to see what the failing write was trying to do
openclaw.json.clobbered.* The active config was replaced or repaired, and this file is the payload that was preserved — per the docs, "doctor preserved a broken external edit while repairing the active config" Possibly. Diff it against the live openclaw.json before doing anything else

One caveat worth stating rather than hiding: the documented producer of .clobbered.* is openclaw doctor --fix, but the reporter in #64419 saw one written during a gateway startup clobber on 2026.4.9, with no doctor run involved. Treat the file as "a payload that was set aside", and let the timestamp — not an assumption about which command made it — tell you when it happened.

What makes OpenClaw call a write a clobber

Not a heuristic you have to guess at. The configuration docs name all three:

"The Gateway blocks writes that look like accidental clobbers — dropping gateway.mode, losing the meta block, or shrinking the file by more than half — unless the write explicitly allows destructive changes."

That is why the #64419 log reads suspicious: ["size-drop:3641->423", "gateway-mode-removed"] — two of the three checks firing on one write. It also explains the failure mode people find most confusing: a write that changes one key without shrinking the file or touching gateway.mode does not look like a clobber at all, so nothing is blocked, nothing is preserved, and your setting simply changes. That is #31251 (2026-03-02, OpenClaw 2026.2.27), where channels.telegram.dmPolicy silently reverted from "open" to "pairing" across a plugin install and uninstall. The guard is a floor against catastrophic writes, not a change-control system.

Which write overwrote your OpenClaw config?

Every documented case is the same defect from a different entry point: a surface loads the config, keeps only the part it understands, and writes the whole file back. Match your symptom to the writer before you start restoring:

The write What you lose The tell
openclaw configure (the wizard) Every key the wizard's UI doesn't manage. In #9632 (2026-02-05, 2026.2.2-3): tools.media.audio, gateway.auth.allowTailscale, and 22 disabled skills entries Loss lines up exactly with a re-run of setup; only wizard-managed sections survive
The Studio / Control UI raw-JSON editor Real values replaced by display placeholders. In #13058 (2026-02-10, CLI v2026.2.9) redacted markers were written back to disk, turning maxTokens: 8192 into the string "__OPENCLAW_REDACTED__" and taking every API key and bot token with it Startup fails with a type error such as Invalid input: expected number, received string
openclaw config set Everything, in the failure case. #6070 (2026-02-01, 2026.1.30) — when the snapshot read failed, an empty object was persisted and the file went from 3.6 KB to 65 B, losing auth profiles, agents, channels, the gateway token, skills, plugins and hooks The surviving config contains roughly only the key you just set. Fixed via PR #11949 — check your version before blaming yourself
openclaw plugins install / uninstall Unrelated keys quietly reverting to defaults (#31251) No error, no .clobbered file — a behaviour change you notice days later. Closed as not planned, so check it after every plugin operation
Gateway startup Custom defaults and gateway.mode (#64419) The size-drop / gateway-mode-removed log line, and a .clobbered file stamped at boot time
Anything outside OpenClaw Whatever the runtime wrote and your external writer doesn't know about — env.vars.*, wizard state, agent-toggled skills Loss recurs on a schedule: every restart, every config push, every deploy. See below — this one is ours

Two of these are fixed upstream (#6070 via PR #11949, and the doctor storm in #56450), so upgrading is a real step and not a platitude. Three others — #13058, #31251 and #9632 — were closed as not planned, which means the behaviour is something to work around rather than wait out.

Why you have thousands of openclaw.json.clobbered files

Because something is writing the config in a loop. OpenClaw does not accumulate these indefinitely — the troubleshooting docs state it "keeps the latest 32 .clobbered.* files for each config path and rotates older ones", so a directory listing in the thousands is a live storm, not history.

Two upstream reports show the two shapes it takes. In #56450 (2026-03-28, OpenClaw 2026.3.11, also seen on 2026.3.24) the repair tool was the source: a single openclaw doctor --fix --yes run produced 675 config.observe events, with each read creating a new clobbered file. In #55797 (2026-03-27, OpenClaw 2026.3.24, Kubernetes with a persistent volume) an openclaw models auth login --provider openai-codex triggered a write-collision loop that reached 13,608 files shortly after login, and 160,622 at its peak, alongside a CPU spike and empty logs.

The operational point: stop the writer before you clean up. Deleting the files while the loop is running only makes room for the next batch, and on a container with a persistent volume you will exhaust inodes long before you exhaust disk. Note also that #55797 is the containerised case — a persistent config directory plus an external write path is what turns a single bad write into a storm.

How to get your settings back

  1. Stop whatever is writing. If the file count is still climbing, halt the gateway, the deploy loop, or the config-management run first. Everything below assumes a directory that has stopped moving.
  2. Read the newest preserved payload before you edit anything. List ~/.openclaw/ by modification time and open the most recent openclaw.json.clobbered.*, openclaw.json.rejected.* and openclaw.json.bak*. One of them holds the keys you're missing — in #13058 the working recovery was exactly this, restoring from openclaw.json.bak.*.
  3. Diff, don't guess. Compare that file against the live openclaw.json and read the removed keys. This is faster and far more reliable than reconstructing your setup from memory, and it tells you which writer did it — a wizard loss and a placeholder loss look nothing alike in a diff.
  4. Validate, then let doctor repair. Run openclaw config validate, then openclaw doctor --fix. This ordering matters because of something the docs are explicit about: the gateway keeps a trusted last-known-good copy after each successful startup, but "startup and hot reload do not restore it automatically — only openclaw doctor --fix does". Waiting for a restart to heal it will not work. If the gateway is already refusing to start on a schema error, our guide to "Gateway failed to start: Invalid config" covers the version-rename causes specifically.
  5. Re-apply what's missing granularly. Use openclaw config set per key and openclaw models auth login --provider <name> for credentials. Do not re-run the full wizard to restore settings — per #9632 that is one of the ways people lose them in the first place.
  6. Edit by hand only with the whole file. The docs are clear that direct edits "are treated as untrusted until they validate", that the watcher waits for temp-write churn to settle, and that invalid external edits are rejected without OpenClaw rewriting openclaw.json. If you hand-edit, write back the complete config, not the fragment you meant to change.
  7. Then prune, keeping the newest. Only once the writer is fixed. Keep the most recent .clobbered and .rejected files — they are the only copy of what you lost.

If something outside OpenClaw writes your config

This is the case the vendor docs and the issue threads don't cover, and it's the one we know from the inside — because Lobsterland is an external writer. Our control plane renders each instance's openclaw.json from database state and pushes it, which means we hit OpenClaw's clobber guard from the far side.

Here is what that costs when you get it wrong. Our config generator built the file purely from stored state and never emitted an env block, and the sync script wrote the result over the top of whatever was there. But the runtime and the agent write to that same file: env.vars.* secrets the owner hands the agent in chat, wizard state, skills the agent toggled. So every config push silently erased them. On 2026-07-22 an owner gave their agent an Asana token, the agent correctly persisted it as env.vars.ASANA_PAT, a config push at 13:11 rewrote the file, and 222 ASANA_PAT is not set failures followed across sessions and crons — with 15.6k on a sibling instance before we caught it. OpenClaw's own clobber detection was firing on our writes the whole time; the .clobbered files on the volume were the tell we should have read sooner.

The fix generalises, so it's worth stating plainly for anyone whose config is produced by a template, a Helm chart, an init container or an Ansible run: never overwrite a config that something else also writes — do a three-way merge. Ours keeps three documents: the config currently on disk, the config we just rendered, and a stored snapshot of the previous render. Rendered keys win conflicts; keys we never rendered are the runtime's and are preserved untouched; keys we rendered before and no longer do are genuine retractions and get dropped, so removing a channel in the dashboard still propagates. If the on-disk config is unreadable we fall back to a plain overwrite; if our own rendered config is unreadable we abort and leave the volume alone.

And one limit worth inheriting along with the pattern, because it bit us later: a merge can only retract what it previously rendered. Anything written before the snapshot file existed has no base entry, gets classified as agent-authored, and is preserved forever. That stayed harmless until an upstream provider id was removed rather than deprecated in OpenClaw 2026.7.1 — at which point a leftover block that our merge had faithfully protected for months hard-failed gateway startup with Invalid config. We now apply known provider-id renames explicitly during the merge, gated so instances still on a pre-rename build are untouched. If you build one of these, decide up front what happens to keys that predate your snapshot.

Stop babysitting your OpenClaw box

Fix it once — or stop fixing it for good.

Apply the checklist above and keep self-hosting, or skip the maintenance entirely: run your OpenClaw on managed hosting from $6.90/mo, starting with a 7-day free trial. We handle the stale locks, gateway restarts, version upgrades, and uptime — and you can import your existing instance in a couple of minutes. Cancel anytime.

Managed hosting — from $6.90/mo Your own hosted OpenClaw instance with automatic restarts and version upgrades. Starts with a 7-day free trial — import your current setup, keep your channels, cancel anytime.
$199 managed setup — optional Prefer we do it for you? One workspace configured end-to-end: first-run config, one 30-minute onboarding/debug session, and a 7-day follow-up. Limited weekly slots.
  • Managed hosting handles stale .jsonl.lock files, gateway restarts, and version upgrades for you
  • Import your existing OpenClaw setup in minutes — keep your channels and configuration
  • The optional $199 setup is scoped: no custom development, enterprise/SRE support, or unsupported self-hosting repair

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

OpenClaw import first screen in OpenClaw Setup dashboard (light theme) OpenClaw import first screen in OpenClaw Setup dashboard (dark theme)
1) Paste import payload
OpenClaw import completed screen in OpenClaw Setup dashboard (light theme) OpenClaw import completed screen in OpenClaw Setup dashboard (dark theme)
2) Review and launch
What managed hosting does and doesn't change here

Being precise about this, because half of it is upstream. Managed hosting does not patch OpenClaw's clobber guard. The heuristics, the .clobbered and .rejected files, the last-known-good copy and openclaw doctor --fix all behave identically on a hosted instance, and any host claiming to have removed that behaviour would be describing something else. What changes is the writer. On managed OpenClaw hosting from Lobsterland the control plane that renders your config performs the three-way merge described above on every write, so the recurring-loss shape — settings that come back wrong after each restart or deploy — is a class of problem the platform owns rather than one you rediscover. Config delivery is versioned and reproducible, so a bad render is a rollback rather than a forensics exercise across timestamped files. If the setting you lost was an agent-set environment variable, the OpenClaw subagent env vars missing guide covers that symptom from the other end.

Frequently asked questions

What is an openclaw.json.clobbered file?

It is a timestamped copy of a config payload that OpenClaw set aside instead of leaving in place. The OpenClaw troubleshooting docs describe it as the file doctor writes when it preserved a broken external edit while repairing the active config: "openclaw doctor --fix owns repair. It can remove non-JSON prefixes or restore the last-known-good copy while preserving the rejected payload as .clobbered.*". It is written next to the active config, so you will see openclaw.json.clobbered.2026-04-10T14-28-24-105Z style names in ~/.openclaw/. Finding one means the active config was replaced or repaired — the file is the evidence, not the damage.

What is the difference between openclaw.json.clobbered and openclaw.json.rejected?

A .rejected file means the write never landed and your active config was left alone; a .clobbered file means the active config was replaced or repaired and the old payload was preserved. The OpenClaw troubleshooting docs put it as two separate signals: ".rejected.* exists → an OpenClaw-owned config write failed schema or clobber checks before commit" and ".clobbered.* exists → doctor preserved a broken external edit while repairing the active config". So .rejected is the protection working, and .clobbered is the record of a replacement that already happened. Check which one you have before you assume you lost anything.

What makes OpenClaw treat a config write as a clobber?

Three specific heuristics. The OpenClaw configuration docs state: "The Gateway blocks writes that look like accidental clobbers — dropping gateway.mode, losing the meta block, or shrinking the file by more than half — unless the write explicitly allows destructive changes." Issue #64419 (2026-04-10, OpenClaw 2026.4.9) shows two of those three firing at once in a real log line: suspicious: ["size-drop:3641->423", "gateway-mode-removed"], with the file dropping from 3641 bytes to 423. If your config lost more than half its size or its gateway.mode key, that is the check you tripped.

Why do I have thousands of openclaw.json.clobbered files?

Because something is writing the config in a loop, not because OpenClaw keeps history. OpenClaw retains a bounded number of these files — the troubleshooting docs say it "keeps the latest 32 .clobbered.* files for each config path and rotates older ones" — so a count in the thousands is a live write storm. Two upstream reports show the shape: #56450 (2026-03-28, OpenClaw 2026.3.11) recorded 675 config.observe events from a single openclaw doctor --fix run, with each read creating a new clobbered file; #55797 (2026-03-27, OpenClaw 2026.3.24, Kubernetes with a persistent volume) reached 13,608 files shortly after openclaw models auth login --provider openai-codex, and 160,622 at its peak. Stop the writer first; deleting files while the loop runs just makes room for more.

How do I recover the settings my OpenClaw config lost?

Work from the newest preserved payload, not from memory. Stop whatever is writing the config, then list ~/.openclaw/ by modification time and read the newest openclaw.json.clobbered.*, openclaw.json.rejected.* and openclaw.json.bak.* files — one of them holds the keys you are missing. Diff that file against the active openclaw.json to see exactly what disappeared rather than guessing. Then run openclaw config validate, and openclaw doctor --fix, which the docs describe as the only thing that restores the last-known-good copy: startup and hot reload do not do it for you. Re-apply the missing settings with granular openclaw config set commands rather than re-running the full wizard, which is itself one of the reported ways to lose them.

Does managed OpenClaw hosting stop config clobbering?

It does not patch OpenClaw's clobber guard, and it would be wrong to claim otherwise — the guard, the .clobbered and .rejected files and doctor --fix all behave exactly the same on a hosted instance. What changes is the writer. Lobsterland's control plane renders instance config and pushes it, which is the external-writer pattern that causes this class of loss, so instead of overwriting the file it performs a three-way merge on every write: keys the control plane renders win, keys it never rendered are preserved, and keys it rendered before and has since dropped are retracted against a stored snapshot of the previous render. We built that after an overwrite wiped an owner-supplied env.vars secret from a live instance. The guard is upstream; the discipline of the thing writing your config is what a host can actually own.

Sources

  • OpenClaw docs — Gateway configuration — the clobber heuristics (gateway.mode, meta block, half-size drop), <path>.rejected.<timestamp>, the last-known-good copy, and the untrusted-direct-edit watcher.
  • OpenClaw docs — Gateway troubleshooting — the .clobbered.* vs .rejected.* signals, doctor's repair ownership, and the 32-file retention and rotation.
  • OpenClaw docs — openclaw config — whole-file recovery is reserved for doctor repair.
  • openclaw#64419 — gateway startup clobbers openclaw.json (3641 → 423 bytes), 2026-04-10, OpenClaw 2026.4.9, closed.
  • openclaw#56450 — doctor --fix generates thousands of clobbered backup files, 2026-03-28, OpenClaw 2026.3.11, closed.
  • openclaw#55797 — models auth login triggers a clobbered storm in a containerized pod (13,608 files; 160,622 at peak), 2026-03-27, OpenClaw 2026.3.24, closed.
  • openclaw#13058 — Studio GUI writes __OPENCLAW_REDACTED__ placeholders back to disk, 2026-02-10, CLI v2026.2.9, closed as not planned.
  • openclaw#31251 — plugin install/uninstall clobbers unrelated keys (dmPolicy reverts), 2026-03-02, OpenClaw 2026.2.27, closed as not planned.
  • openclaw#9632 — openclaw configure wizard drops custom keys, 2026-02-05, OpenClaw 2026.2.2-3, closed as not planned.
  • openclaw#6070 — openclaw config set overwrites the entire config when the snapshot read fails (3.6 KB → 65 B), 2026-02-01, OpenClaw 2026.1.30, closed via PR #11949.
  • openclaw#1661 — the Control UI raw-JSON editor writes the full config instead of a partial change.

Related fixes

Cookie preferences