[Bug]: Brave plugin install + tools.web.search.provider: "brave" causes 1.2s crash loop with no CLI escape (5.2 beta)

Bug type

Regression / Crash loop (worked before 5.2)

Beta release blocker

Yes — 5.2 brick scenario with no openclaw gateway stop recovery path.

Severity

High. Workaround exists (launchctl bootout + manual JSON edit), but recovery requires shell + config-editing skill, and the loop fills logs at ~50 restarts/min (~5MB in 3 min observed).

Summary

After upgrading to 2026.5.2, restoring Brave search via openclaw plugins install @openclaw/brave-plugin + setting tools.web.search.provider: "brave" puts the gateway into a tight crash loop (~1.2s/restart) that cannot be broken by openclaw gateway stop. Recovery requires killing the launchd service and manually editing openclaw.json.

The loop is sustained by three compounding bugs, any one of which would break the loop on its own.

Steps to reproduce

1. Upgrade to OpenClaw 2026.5.2 (commit 8b2a6e5)
2. openclaw plugins install @openclaw/brave-plugin — succeeds, writes install record
3. Edit ~/.openclaw/openclaw.json:

   {
     "tools": { "web": { "search": { "provider": "brave" } } },
     "plugins": {
       "allow": ["brave"],
       "entries": {
         "brave": { "enabled": true, "config": { "webSearch": { "apiKey": "BSA..." } } }
       }
     }
   }

4. Gateway hot-reloads → enters crash loop within seconds
5. openclaw gateway stop does not return cleanly (we believe blocked by config validation; see issue WA business, groups & office hours  #3 below)
6. Loop only ends with launchctl bootout gui/$UID/ai.openclaw.gateway (macOS) or kill -9 <pid> (Linux)

Observed behavior

Gateway error log shows the same message repeating every ~1.2 seconds:

[gateway] Gateway failed to start: Error: Invalid config at /Users/.../.openclaw/openclaw.json.
tools.web.search.provider: web_search provider is not available: brave
(install or enable plugin "brave", then run openclaw doctor --fix)

[gateway] Config auto-restored from last-known-good: /Users/.../.openclaw/openclaw.json
(startup-invalid-config); Rejected validation details: tools.web.search.provider: ...

[gateway] wrote stability bundle: .../logs/stability/openclaw-stability-*-gateway.startup_failed.json

Three compounding root causes

Issue #1 — Brave plugin loads but fails to register web_search provider

The npm package @openclaw/brave-plugin@2026.5.2 ships only TypeScript source (no compiled dist/):

@openclaw/brave-plugin/
├── index.ts                              # entry; openclaw.extensions points here
├── openclaw.plugin.json
├── package.json                          # declares "openclaw.extensions": ["./index.ts"]
└── src/
    ├── brave-web-search-provider.ts
    ├── brave-web-search-provider.runtime.ts
    └── brave-web-search-provider.shared.ts

The gateway successfully transpiles index.ts via jiti (output observed at ~/.openclaw/tmp/jiti/brave-plugin-index.*.cjs), but provider registration silently fails, producing the runtime error web_search provider is not available: brave.

Likely culprit: index.ts imports ./src/brave-web-search-provider.js (note .js extension on a path that only exists as .ts). jiti's resolver may be inconsistent across this hop, or createBraveWebSearchProvider() is throwing inside register() and being swallowed.

Either way: a published plugin release artifact should not ship as raw TS without a compiled dist/.

Issue #2 — Config auto-restore restores the same broken config in a loop

When validation rejects the config because Brave isn't available, the gateway "restores from last-known-good" — but the last-known-good IS the rejected config (it was valid when written; the validator only fails after observing the unloadable provider at startup).

Confirmed in ~/.openclaw/logs/config-audit.jsonl — every restore event shows:

{
  "hash":              "71c5705c726673bebbb869b5b098ca912b557e7f9531bb624ead931c2a010677",
  "lastKnownGoodHash": "71c5705c726673bebbb869b5b098ca912b557e7f9531bb624ead931c2a010677",
  "restoredFromBackup": true,
  "suspicious": ["startup-invalid-config"]
}

The hashes are identical. The gateway is restoring a config to itself, then rejecting it, then restoring it again, ~50 times per minute.

The restore logic should detect "I just restored a config with this hash and it failed validation" and either (a) refuse to restore (force operator intervention), (b) disable the offending plugin from the restored copy, or (c) fall back to a built-in safe provider (duckduckgo).

This is the same class of bug as #29745 (infinite retry loop with no backoff) and is essentially the missing piece of #17700 ("save last-known-good only after gateway healthy >10s").

Issue #3 — openclaw gateway stop appears to validate config, blocking recovery

We could not break the loop with openclaw gateway stop. Per OpenClaw's troubleshooting docs, lifecycle commands run config validation up-front; if so, stop is unreachable while the config is invalid. Please confirm in repro — if validated, this should be removed for stop (a stop command should never be blocked by config state).

Expected behavior

1. Plugin packaging: @openclaw/brave-plugin should ship pre-compiled JS, OR the gateway plugin loader should fail loudly (not silently) when a plugin loads but fails to register its declared contracts.
2. Restore loop: Detect "restored config equals just-failed config" → either refuse to restore (force operator action) or disable the offending plugin in the restored copy. Add startup backoff (exponential ≥ 30s) after N consecutive validation failures.
3. gateway stop: Must never validate config. Stopping a process is unconditional.

Environment

• OpenClaw: 2026.5.2 (commit 8b2a6e5)
• OS: macOS 15.4.1 (arm64, Darwin 25.3.0)
• Node: v22.22.2
• Install: Homebrew (/opt/homebrew/lib/node_modules/openclaw)
• LaunchAgent: gui/$UID/ai.openclaw.gateway
• Brave plugin: @openclaw/brave-plugin@2026.5.2 (sha512: NF+v2ox7/nhddfuCIAzL9HKlIyt8gZw+3+1Nb73SfBvUfh+dzF++tUrKgqrXBtgAhDlYyNl3NDCsIccIaVYtuw==)

Evidence to collect (for repro / triage)

• ~/.openclaw/logs/gateway.err.log (look for repeating "Config auto-restored from last-known-good")
• ~/.openclaw/logs/config-audit.jsonl (hash equality between hash and lastKnownGoodHash is the smoking gun)
• ~/.openclaw/logs/stability/openclaw-stability-*-gateway.startup_failed.json (one per crash)
• ~/.openclaw/tmp/jiti/brave-plugin-index.*.cjs (confirms TS load worked but registration didn't)

Recovery (for anyone hitting this)

# 1. Break the loop (gateway stop won't work)
launchctl bootout gui/$UID/ai.openclaw.gateway   # macOS
# OR
kill -9 $(pgrep -f 'openclaw.*gateway')          # Linux

# 2. Edit ~/.openclaw/openclaw.json:
#    - tools.web.search.provider: "brave" → "duckduckgo" (or "searxng")
#    - Remove plugins.entries.brave
#    - Remove "brave" from plugins.allow

# 3. Restart
openclaw gateway start

Related

• [Bug]: Config validation error causes infinite retry loop with no backoff — 1GB error log from single invalid key #29745 — Config validation infinite retry loop (no backoff). Same outcome class.
• feat: atomic config management with validation and crash-loop rollback #17700 — feat: atomic config management with validation and crash-loop rollback. Would have prevented this.
• Plugin config error causes hard gateway crash instead of graceful disable #60143 — Plugin config error causes hard gateway crash instead of graceful disable. Adjacent (different mechanism, same "one bad plugin tanks gateway" theme).
• Gateway crash loop: no backoff or circuit-breaker on auto-restart #60142 — Gateway crash loop: no backoff/circuit-breaker on auto-restart.
• [Bug]: Gateway self-induced hot-reload loop corrupts manifest.db on Linux VPS #67436 — Gateway self-induced hot-reload loop corrupts manifest.db (Linux VPS). Brave is one of the auto-provisioned plugins implicated there.
• [Bug]: 5.2 brave plugin install fails — missing openclaw.extensions, no @beta available #76373 — Different bug: 0.0.9 stable npm package missing openclaw.extensions. Our package (5.2) has the manifest but ships no compiled JS.