openclaw - 💡(How to fix) Fix web_search: Perplexity provider returns 401 despite valid PERPLEXITY_API_KEY and direct API success [1 participants]

Bug

OpenClaw's native web_search tool returns 401 invalid_api_key when configured to use the Perplexity provider, despite the same PERPLEXITY_API_KEY succeeding in a direct API call to https://api.perplexity.ai/chat/completions.

This appears to be an OpenClaw runtime/provider credential-resolution bug, not a Perplexity account/key issue.

Environment

• OpenClaw installed via Homebrew
• Runtime path: /opt/homebrew/lib/node_modules/openclaw
• Gateway launched via macOS LaunchAgent
• Host: macOS (Apple Silicon)
• tools.web.search.provider = "perplexity"

What was verified

1. The Perplexity key is valid

A fresh key from the real Perplexity API console succeeds directly against Perplexity's API on the same machine.

Example:

curl -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"sonar-pro","messages":[{"role":"user","content":"test"}]}' \
  https://api.perplexity.ai/chat/completions

Result: HTTP 200

2. Native OpenClaw web_search still fails

Using the same machine and same credential, OpenClaw native web_search returns:

{
  "error": {
    "message": "Invalid API key provided. You can find your API key at https://www.perplexity.ai/settings/api.",
    "type": "invalid_api_key",
    "code": 401
  }
}

3. LaunchAgent env drift was fixed first

The LaunchAgent originally had a stale baked PERPLEXITY_API_KEY that differed from ~/.openclaw/.env.

That was corrected:

• synced LaunchAgent env to the same fresh key
• restarted gateway

This removed the obvious env drift issue, but native web_search still returned 401.

4. Local runtime patch attempt did not fix it

A local patch was attempted in the installed dist runtime to prioritize process.env.PERPLEXITY_API_KEY inside the Perplexity provider path.

Even after:

• patching the installed runtime
• verifying launchd env
• restarting the gateway

native web_search still returned 401.

That suggests the bug may not be limited to a simple fallback issue. It may also involve:

• wrong config path resolution
• stale provider instance/runtime caching
• downstream credential overwrite/normalization
• plugin/runtime split between config surfaces

Config paths involved

The following config surfaces were involved during debugging:

• tools.web.search.provider = "perplexity"
• plugins.entries.perplexity.config.webSearch.apiKey
• attempted tools.web.search.perplexity.apiKey
• process.env.PERPLEXITY_API_KEY

Most implicated files

Installed runtime files examined:

• dist/perplexity-web-search-provider-*.js
• dist/extensions/perplexity/web-search-contract-api.js
• dist/web-search-provider-config-*.js
• dist/provider-web-search-contract-fields-*.js
• dist/provider-web-search-*.js
• dist/runtime-web-tools-*.js
• dist/attempt.tool-run-context-*.js

Most suspicious areas:

• Perplexity API key resolution
• scoped credential/config resolution
• runtime provider selection
• request header construction
• reload/restart propagation of config changes

Expected behavior

If PERPLEXITY_API_KEY is valid and available in the gateway environment, native web_search with provider perplexity should succeed.

Actual behavior

Native web_search returns Perplexity 401 even when:

• the same key works directly via curl
• the LaunchAgent env is correct
• the gateway has been restarted
• the installed provider code was locally patched to prefer env

Why this matters

This produces a misleading operational failure mode where users are told their Perplexity API key is invalid when the real issue appears to be internal credential/provider resolution inside OpenClaw.

Suggested debugging targets

Please inspect:

1. whether the live request path is actually using the patched/current resolver
2. whether an empty/stale scoped config value shadows env fallback
3. whether the provider instance caches credentials before config reload
4. whether plugin config and runtime web-search config use different sources of truth
5. what exact Authorization header value is ultimately sent on the Perplexity request path

Workaround

Direct Perplexity API calls work correctly outside native web_search, so users can route Perplexity-backed research through direct scripts/API clients until the runtime issue is fixed.