Cant fix my config

[fierce laurel]

Hello!

My openclaw agent hallucinated some unexistend commands for config, and now I cant erease it. Please @near ravine Help!

Error:

Invalid config at /home/user/.openclaw/openclaw.json:\n- plugins.deny: plugin not found: memory-lancedb

🦞 OpenClaw 2026.5.7 (eeef486) — WhatsApp automation without the "please accept our new privacy policy".

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

• plugins.deny: plugin not found: memory-lancedb

Run: openclaw doctor --fix

The practical result: openclaw config reports "Config invalid" and the gateway rejects the configuration.
However, the real problem is worse than just an invalid config file. The gateway exhibits a persistent config restoration behavior:

1. Manually fixing the broken openclaw.json (removing plugins.deny and memory-lancedb from plugins.entries) appears to work on disk.
2. But when the gateway starts, it overwrites the corrected config with the previously cached broken version — restoring memory-lancedb entries and denying the fix.
3. Attempts to delete the recovery/fallback files were made:
   • Removed last-good configuration snapshots
   • Removed .bak backup configs
   • Attempted workspace-level cleanup
4. Despite these deletions, the broken config is always restored upon gateway startup — the invalid state survives every attempt to overwrite it.

The gateway is essentially locked in a loop: it stores a "last-known" config (the broken one), and on every restart it restores that cached version, discarding any manual corrections. The fix needs to happen at the source of the cached config — it cannot be resolved by simply editing the JSON file. I cant even execute commands like "openclaw config unset" because of that stupid error

"plugins": {
...
"deny": [
"memory-core",
"memory-lancedb"
]
}

[potent echo]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[near ravine]

debaser I checked the docs/source. In this case the “cached config” is real: gateway startup can restore an invalid config from ~/.openclaw/openclaw.json.last-good, and config read recovery can also restore from ~/.openclaw/openclaw.json.bak. The hash/state that controls that lives in ~/.openclaw/logs/config-health.json.

Do this with the gateway stopped, and move files aside instead of deleting them:

openclaw --version
openclaw gateway stop

ts="$(date +%Y%m%d-%H%M%S)"
cp -a ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-memory-lancedb-fix.$ts

# find every remaining reference, including included config files
rg -n 'memory-lancedb|\$include|plugins\.deny|plugins.*entries' ~/.openclaw

Then edit the file(s) from that rg output and remove:

• memory-lancedb from plugins.deny

[near ravine]

• plugins.entries.memory-lancedb if present

Important bit: after the fixed config is on disk, disable the restore sources:

ts="$(date +%Y%m%d-%H%M%S)"
for f in ~/.openclaw/openclaw.json.last-good ~/.openclaw/openclaw.json.bak ~/.openclaw/logs/config-health.json; do
  [ -e "$f" ] && mv "$f" "$f.disabled.$ts"
done

openclaw doctor --fix
openclaw gateway start
openclaw gateway status

Why this should break the loop: startup restore requires openclaw.json.last-good plus the promoted-good hash in logs/config-health.json; suspicious-read restore uses openclaw.json.bak. Moving all three aside forces OpenClaw to accept the fixed config instead of resurrecting the old one.

[near ravine]

Docs refs: https://docs.openclaw.ai/help/faq, https://docs.openclaw.ai/gateway/doctor, https://docs.openclaw.ai/gateway/configuration-reference#config-includes

[fierce laurel]

Gateway stop blocked: plugins.deny: plugin not found: memory-lancedb

[near ravine]

Yep, openclaw gateway stop goes through the OpenClaw CLI config guard, so the bad config can block the stop command too.

Bypass the CLI and stop the supervisor directly.

Linux user service, most likely for your /home/user path:

systemctl --user stop openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager

If it was installed as a system service:

sudo systemctl stop openclaw-gateway.service
sudo systemctl status openclaw-gateway.service --no-pager

[near ravine]

macOS, if relevant:

launchctl bootout gui/$UID/ai.openclaw.gateway

After that, do the config cleanup from the previous message. Since openclaw config is blocked, use an editor and rg:

rg -n 'memory-lancedb|\$include|plugins\.deny' ~/.openclaw
nano ~/.openclaw/openclaw.json

Then move aside the restore state:

[near ravine]

ts="$(date +%Y%m%d-%H%M%S)"
for f in ~/.openclaw/openclaw.json.last-good ~/.openclaw/openclaw.json.bak ~/.openclaw/logs/config-health.json; do
  [ -e "$f" ] && mv "$f" "$f.disabled.$ts"
done

If systemctl --user stop says no such unit, paste the output of:

systemctl --user list-units 'openclaw*' --no-pager
systemctl list-units 'openclaw*' --no-pager

[fierce laurel]

is this means its off? daniil@abdalbuntu:~/.openclaw/logs$ systemctl --user stop openclaw-gateway.service
daniil@abdalbuntu:~/.openclaw/logs$ systemctl --user status openclaw-gateway.service --no-pager
× openclaw-gateway.service - OpenClaw Gateway (v2026.5.7)
Loaded: loaded (/home/daniil/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Tue 2026-05-19 09:11:22 +05; 5min ago
Duration: 2.179s
Process: 514689 ExecStart=/home/linuxbrew/.linuxbrew/opt/node/bin/node /home/daniil/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (code=exited, status=1/FAILURE)
Main PID: 514689 (code=exited, status=1/FAILURE)
CPU: 2.996s

May 19 09:11:22 abdalbuntu systemd[1406]: openclaw-gateway.service: Scheduled restart job, restart counter is at 5.
May 19 09:11:22 abdalbuntu systemd[1406]: openclaw-gateway.service: Start request repeated too quickly.
May 19 09:11:22 abdalbuntu systemd[1406]: openclaw-gateway.service: Failed with result 'exit-code'.
May 19 09:11:22 abdalbuntu systemd[1406]: Failed to start openclaw-gateway.service - OpenClaw Gateway (v2026.5.7).
May 19 09:11:22 abdalbuntu systemd[1406]: openclaw-gateway.service: Consumed 2.996s CPU time.
daniil@abdalbuntu:~/.openclaw/logs$

[near ravine]

Yes: Active: failed means the gateway is not running right now. It’s “off” in the sense that there’s no active gateway process, but it’s not a clean stopped state — systemd is remembering that it crashed/restarted too many times.

Two important bits:

• Loaded: ... enabled means it is still configured to auto-start on login/boot.
• Active: failed (Result: exit-code) means the last start attempt exited with error.

If you only wanted it stopped for now, this is enough:

systemctl --user stop openclaw-gateway.service
systemctl --user reset-failed openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager

After that you’d expect inactive (dead).

If you want to prevent it from auto-starting too:

[near ravine]

systemctl --user disable --now openclaw-gateway.service
systemctl --user reset-failed openclaw-gateway.service

For fixing why it crashed, next useful outputs are:

openclaw --version
journalctl --user -u openclaw-gateway.service -n 120 --no-pager
openclaw status --all

Docs troubleshooting path: https://docs.openclaw.ai/gateway/troubleshooting

[fierce laurel]

where openclaw searches for the backup configs? Because I deleted every one of them, and it still returns... daniil@abdalbuntu:~/.openclaw$ ls
acpx extensions plugins
agents flows plugin-skills
cache identity qqbot
canvas locks restart-sentinel.json.5282833d-3f52-41ba-a827-d07bd6049587.tmp
completions logs session-delivery-queue
credentials media skills
cron memory subagents
data memory-braid tasks
delivery-queue npm telegram
devices old_configs update-check.json
exec-approvals.json openclaw02032026.json.bak workspace
express-messenger openclaw.json

[near ravine]

OpenClaw doesn’t scan old_configs/ or random *.bak names for the active config. It resolves the active config path first, then looks for recovery files next to that exact file.

For your usual setup the active file is probably:

~/.openclaw/openclaw.json

The recovery files it can use beside that are mainly:

~/.openclaw/openclaw.json.bak
~/.openclaw/openclaw.json.bak.1
~/.openclaw/openclaw.json.bak.2
~/.openclaw/openclaw.json.bak.3
~/.openclaw/openclaw.json.bak.4
~/.openclaw/openclaw.json.last-good
~/.openclaw/openclaw.json.clobbered.*

[near ravine]

~/.openclaw/openclaw.json.rejected.*

The one that often surprises people is openclaw.json.last-good. Startup can restore from that if the current config is invalid/clobbered. It also tracks the last-good metadata in:

~/.openclaw/logs/config-health.json

First check the exact active config path:

openclaw config file

Then inspect files around that path:

[near ravine]

CONFIG="$(openclaw config file)"
ls -la "$(dirname "$CONFIG")" | grep "$(basename "$CONFIG")"

Also check if systemd is forcing another config path through env:

systemctl --user show openclaw-gateway.service -p Environment --no-pager
systemctl --user cat openclaw-gateway.service

Config path resolution order is roughly: OPENCLAW_CONFIG_PATH first, then OPENCLAW_STATE_DIR/openclaw.json, then default ~/.openclaw/openclaw.json, with legacy clawdbot.json / ~/.clawdbot fallbacks.

Docs for this recovery behavior: https://docs.openclaw.ai/gateway/troubleshooting

[fierce laurel]

i dont know its still recovers into a broken state somehow

[near ravine]

That means the “known good” copy OpenClaw is recovering from is probably also bad, or the service is reading a different config path than the one you’re cleaning.

I’d stop the service and quarantine the recovery files beside the actual active config path, then validate before starting again:

openclaw --version
systemctl --user stop openclaw-gateway.service
systemctl --user reset-failed openclaw-gateway.service

CONFIG="$(openclaw config file)"
echo "$CONFIG"
mkdir -p "$(dirname "$CONFIG")/bad-config-recovery"

mv "$CONFIG".bak* "$CONFIG".last-good "$CONFIG".clobbered.* "$CONFIG".rejected.* "$(dirname "$CONFIG")/bad-config-recovery/" 2>/dev/null
mv ~/.openclaw/logs/config-health.json ~/.openclaw/logs/config-health.json.bad 2>/dev/null

[near ravine]

openclaw config validate

If openclaw config validate still says the current config is broken, don’t start the gateway yet. Fix $(openclaw config file) first, or temporarily move the active config aside too:

CONFIG="$(openclaw config file)"
mv "$CONFIG" "$(dirname "$CONFIG")/bad-config-recovery/openclaw.json.active-bad"
openclaw doctor

Also run this because I’m suspicious systemd may be using a different env/config path:

systemctl --user show openclaw-gateway.service -p Environment --no-pager

[near ravine]

systemctl --user cat openclaw-gateway.service

If you paste openclaw --version, openclaw config file, and the exact openclaw config validate error, we can pin down whether it’s bad last-good recovery, wrong config path, or a schema issue. Docs path for the recovery behavior: https://docs.openclaw.ai/gateway/troubleshooting

[fierce laurel]

Could it be that my agent couldn't change the config at one point and instructed itself to add these plugins.deny lines to its startup parameters?

[near ravine]

Mostly: not through normal OpenClaw startup parameters, unless something actually edited your systemd unit/drop-in, wrapper script, or environment.

I checked the current source: openclaw gateway has flags like --port, --token, --auth, --allow-unconfigured, etc. I’m not seeing a generic startup flag like --set plugins.deny=.... So plugins.deny normally comes from one of these places:

~/.openclaw/openclaw.json
# or whatever OPENCLAW_CONFIG_PATH points at

or a runtime-only debug override:

/debug set plugins.deny=...

But /debug overrides are in memory only and should disappear after a gateway restart. If they survive restarts, it’s probably disk/systemd/env/config-path related, not the agent “remembering” it.

[near ravine]

Check these exact places:

openclaw config file
openclaw config get plugins.deny

systemctl --user cat openclaw-gateway.service
systemctl --user show openclaw-gateway.service -p Environment --no-pager
systemctl --user show openclaw-gateway.service -p ExecStart --no-pager

find ~/.config/systemd/user -maxdepth 3 -type f -name '*.conf' -o -name 'openclaw-gateway.service'
grep -R "plugins.deny\|OPENCLAW_CONFIG_PATH\|OPENCLAW_STATE_DIR" ~/.config/systemd/user ~/.openclaw 2>/dev/null

If plugins.deny shows up in systemctl cat or a drop-in under ~/.config/systemd/user/openclaw-gateway.service.d/, then yes, something wrote it into service startup config. If it only shows in openclaw.json / .last-good / .bak, then recovery is pulling it from config recovery state.

One more thing: after changing service files, run:

[near ravine]

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

Otherwise systemd can keep using the old unit definition.

[fierce laurel]

okay, somehow I ereased broken lines in config and managed to launch openclaw update, and aftewr that everything seems to be working, thank you for help!

[near ravine]

Nice, glad you got it unstuck.

Since this looks solved, please mark the solution for Answer Overflow indexing: right-click the solution message → Apps → ✅ Mark Solution. It helps the next person who hits config recovery weirdness find the fix faster.