openclaw - 💡(How to fix) Fix [Bug]: PR #86818 fix doesn't reach inline mergeScopedSearchConfig copies — gateway still crash-loops in v2026.5.26-beta.1 [5 pull requests]

Summary

Confirmed PR #86818 (merged 2026-05-26) ships in [email protected], but the gateway still crash-loops with the same error on a fresh container start:

Gateway failed to start: Invalid config at /data/.openclaw/openclaw.json.
tools.web.search.perplexity: legacy web_search provider config must use plugins.entries.<plugin>.config.webSearch
Run "openclaw doctor --fix" to repair, then retry.

Reopens #86779 effectively.

Verification I ran

1. Rebuilt container with OPENCLAW_BETA=true (npm install -g openclaw@beta) — openclaw --version reports 2026.5.26-beta.1 (64e01ef).
2. Verified the fix IS in dist/web-search-provider-config-BM2hIBV9.js:

   const shouldHideRuntimeInjectedLegacyShape = isLegacyWebSearchProviderConfigKey(key) && existingDescriptor === void 0;
   Object.defineProperty(next, key, {
     value: { ...currentScoped, ...pluginConfig },
     enumerable: !shouldHideRuntimeInjectedLegacyShape,
     configurable: true, writable: true
   });

3. Reset user config to remove ANY perplexity reference: tools.web.search = {enabled: true, provider: "gemini"} only; plugins.entries.perplexity entirely deleted (was enabled: false). Verified with grep -r perplexity openclaw.json returns zero hits.
4. Restarted container → same error.

Likely remaining gap

brave-web-search-provider-D3HX2LYf.js:78 has its own inline copy of mergeScopedSearchConfig (not imported from the fixed module), and uses the plain {...searchConfig, [key]: {...currentScoped, ...pluginConfig}} spread pattern — i.e. enumerable injection, no defineProperty:

function mergeScopedSearchConfig(searchConfig, key, pluginConfig, options) {
	if (!pluginConfig) return searchConfig;
	const currentScoped = isRecord(searchConfig?.[key]) ? searchConfig?.[key] : {};
	const next = {
		...searchConfig,
		[key]: {
			...currentScoped,
			...pluginConfig
		}
	};
	...
}

Even if the bug surfaces on tools.web.search.perplexity and not .brave, the symptom suggests there's a code path (manifest-driven or downstream spread on the merged object) that re-enumerates the property, undoing the enumerable: false from PR #86818.

A separate possibility: even if mergeScopedSearchConfig always returns a non-enumerable property, somewhere downstream the result is being object-spread ({...merged}) which preserves enumerable-only — but those don't re-enumerate the non-enum either. So the most likely source is the inline copies.

Suggested fix

Apply the same defineProperty treatment to every inline copy of mergeScopedSearchConfig (brave, exa, gemini, kimi, minimax, perplexity, etc.). Or — better — make Rollup deduplicate the bundle so all providers import from the single fixed module.

Happy to PR if useful. Filing this so the bundling situation is on the maintainer radar.

Environment

• [email protected] (64e01ef)
• Node v22.19.0, Debian 12 (Docker)
• 11 plugins.entries (anthropic, browser, device-pair, duckduckgo, gemini, google, google-antigravity-auth, minimax, telegram, whatsapp), 0 enabled