PR #74921: fix(secrets): skip web tool discovery when surface is explicitly disabled (#74896)

• Repository: openclaw/openclaw
• Author: lonexreb
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74921

Description (problem / solution / changelog)

Summary

• Symptom: OpenClaw 2026.4.26 gateway starts but never binds its port when tools.web.fetch is present in openclaw.json. With OPENCLAW_GATEWAY_STARTUP_TRACE=1, the trace stops after config.snapshot and never reaches config.auth. Setting tools.web.fetch.enabled=false does not fix it; only removing the tools.web.fetch key entirely lets startup proceed. Reported as a regression on 2026.4.26 in #74896.
• Why it matters: the gateway looks alive but is unreachable. Health checks and local clients can't connect, and the user's "Expected behavior" explicitly asks for enabled=false to be a real escape hatch: "If tools.web.fetch.enabled=false, fetch provider discovery should not block gateway startup."
• What changed: resolveRuntimeWebTools (src/secrets/runtime-web-tools.ts) now short-circuits the search and fetch discovery branches when the tool surface is explicitly enabled: false, has no plugin-scoped config (plugins.entries.<id>.config.web{Search,Fetch}), and carries no nested object fields (no credential subkeys like firecrawl: { apiKey: ... }). The empty-config fast-path early return that already existed for the no-key case is now mirrored at the per-surface granularity.
• What did NOT change: disabled tools that DO carry credential subkeys still run discovery so inactive-surface SecretRef warnings remain accurate (the existing test "keeps configured provider metadata and inactive warnings when search is disabled" still passes). The full root-cause investigation of why bundled manifest discovery stalls on Linux/Docker on this code path is left as a separate concern; this PR delivers the user's explicit enabled: false workaround.

Change Type

• Bug fix

Scope

• API / contracts (config behavior)
• Gateway / orchestration (startup path)

Linked Issue/PR

• Closes #74896
• This PR fixes a bug or regression

Root Cause

resolveRuntimeWebTools reached resolveRuntimeWebProviderSurface → bundled-plugin manifest scan whenever a tool surface had any object in config, regardless of enabled. On affected Linux/Docker environments, that manifest scan during startup secrets activation does not return promptly, so prepareGatewayStartupConfig never resolves and the gateway never reaches the HTTP bind step.

Code flow that hangs (current main):

• prepareSecretsRuntimeSnapshot → resolveRuntimeWebTools (src/secrets/runtime.ts:362)
• resolveRuntimeWebTools enters the if (fetch || hasPluginWebFetchConfig) branch even when fetch.enabled === false (src/secrets/runtime-web-tools.ts:682)
• That branch awaits resolveRuntimeWebProviderSurface → resolveBundledWebFetchProviders → bundled manifest registry load.

This regressed in 74059aaa29 fix(secrets): honor plugin install ledger for web fetch discovery (Apr 25), which threaded await getHasCustomWebFetchRisk() into the fetch resolveProviders callback and added a load to loadRuntimeWebToolsManifest().

Regression Test Plan

3 new tests in src/secrets/runtime-web-tools.test.ts:

• disabled credential-free fetch skips fetch discovery — mirrors the user's exact reproducer config (tools.web.fetch: { enabled: false, maxChars, maxCharsCap }, empty plugins.entries); asserts none of the bundled-public-artifacts mocks or the plugin fallback mock are called.
• disabled credential-free search skips search discovery — same shape on the search side.
• disabled fetch with nested credential block still runs discovery — guards against regressing the "inactive surface SecretRef warning" contract: when fetch.firecrawl.apiKey is a SecretRef, discovery still happens even with enabled: false.

Test Plan

• pnpm test src/secrets/runtime-web-tools.test.ts — 36/36 pass (33 existing + 3 new)
• pnpm tsgo:core — clean
• pnpm tsgo:core:test — clean
• pnpm exec oxfmt --write --threads=1 … — clean

Notes

• Honest scope acknowledgment: I do not have a Linux/Docker repro of the deeper hang, so the underlying manifest-scan stall is not addressed here. This PR ships the user's explicit enabled: false escape hatch and tightens the fast-path to match the no-key case. Full root-cause investigation of the manifest-scan stall (likely in loadRuntimeWebToolsManifest() → bundled plugin discovery on slow filesystems) should land in a follow-up after a maintainer with the affected environment can profile the stall.
• The optimization also incidentally helps users who simply do not need the web fetch tool but want to keep the config key present for documentation/policy reasons.

Changed files

• src/secrets/runtime-web-tools.test.ts (modified, +154/-0)
• src/secrets/runtime-web-tools.ts (modified, +47/-2)

PR #74924: fix(secrets): skip web-fetch provider discovery when tools.web.fetch is explicitly disabled

• Repository: openclaw/openclaw
• Author: hclsys
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74924

Description (problem / solution / changelog)

Problem

When tools.web.fetch is present in openclaw.json with enabled: false, the gateway startup hangs indefinitely before binding its port. Removing the fetch key from config restores normal startup.

Fixes #74896

Root cause

hasRuntimeWebToolConfigSurface returns true for any tools.web.fetch object — including { enabled: false }. This bypasses the secrets fast path and triggers resolveRuntimeWebProviderSurface, which unconditionally awaits resolveProviders() (bundled/plugin web-fetch discovery) regardless of the enabled flag. On network-constrained or Docker environments, provider discovery can stall indefinitely.

Fix

Two-layer guard:

src/secrets/runtime.ts — hasRuntimeWebToolConfigSurface now excludes tools.web.fetch from the slow-path gate when fetch.enabled === false. Disabled-fetch configs use the fast path and skip all provider discovery.

src/secrets/runtime-web-tools.ts — resolveRuntimeWebTools guards the fetch surface resolution block with fetchExplicitlyDisabled, so provider discovery is also skipped at the resolver level for belt-and-suspenders safety (protects callers that invoke resolveRuntimeWebTools directly).

Tests

pnpm test src/secrets/runtime-web-tools.test.ts src/secrets/runtime.fast-path.test.ts src/gateway/server-startup-config.secrets.test.ts

45/45 pass. New regression tests:

• runtime.fast-path.test.ts: "uses the fast path when tools.web.fetch is present but explicitly disabled"
• runtime-web-tools.test.ts: "skips fetch provider discovery when tools.web.fetch.enabled is false"

Changed files

• src/secrets/runtime-web-tools.test.ts (modified, +54/-20)
• src/secrets/runtime-web-tools.ts (modified, +5/-1)
• src/secrets/runtime.fast-path.test.ts (modified, +20/-0)
• src/secrets/runtime.ts (modified, +11/-2)