Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

plugins.entries.firecrawl.config.webFetch.apiKey accepts a 1Password SecretRef and the gateway runtime shows it as resolved/masked, but web_fetch requests routed through Firecrawl fail with 401 Unauthorized: Invalid token.

The exact same Firecrawl token works when stored as plaintext in config, so the failure appears specific to the SecretRef handling/runtime request path for Firecrawl web fetch.

This may be related to SecretRef/runtime materialization issues such as #28359.

Environment

• OpenClaw: 2026.4.11
• OS: Linux
• Runtime: Gateway local mode
• Surface involved: plugins.entries.firecrawl.config.webFetch.apiKey
• Secret provider: 1Password (op://...)

Config used

json
{
"plugins": {
"entries": {
"firecrawl": {
"enabled": true,
"config": {
"webFetch": {
"apiKey": "op://openclaw/Firecrawl API key/credential",
"baseUrl": "https://api.firecrawl.dev",
"onlyMainContent": true,
"maxAgeMs": 86400000,
"timeoutSeconds": 60
}
}
}
}
},
"tools": {
"web": {
"fetch": {
"enabled": true,
"provider": "firecrawl",
"maxChars": 50000,
"maxCharsCap": 50000,
"maxResponseBytes": 2000000,
"timeoutSeconds": 30,
"cacheTtlMinutes": 15,
"maxRedirects": 3,
"readability": true
}
}
}
}

Steps to reproduce

1. Configure Firecrawl fallback for web_fetch.
2. Set plugins.entries.firecrawl.config.webFetch.apiKey to a valid 1Password SecretRef, for example:
   • op://openclaw/Firecrawl API key/credential
3. Restart the gateway.
4. Verify config.get:
   • sourceConfig shows the raw SecretRef
   • resolved / runtime views show the field as resolved/masked, not missing
5. Run:
   • web_fetch("https://example.com")

Expected behavior

web_fetch should succeed through Firecrawl using the SecretRef-resolved API key.

Actual behavior

web_fetch fails with:

text
Firecrawl API error (401): Unauthorized: Invalid token

OpenClaw version

2026.4.11

Operating system

Ubuntu

Install method

No response

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> FIrecrawl

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Control test

If the exact same Firecrawl token is written directly into config as plaintext for:

• plugins.entries.firecrawl.config.webFetch.apiKey

and the gateway is restarted, then:

• web_fetch("https://example.com") succeeds
• extractor/provider is Firecrawl

So the token itself is valid, and the failure is specific to the SecretRef path.

Additional observations

• The schema allows plugins.entries.firecrawl.config.webFetch.apiKey as string | object.
• Runtime config inspection suggests the gateway accepts and resolves the SecretRef at config level.
• The failing behavior appears to happen later, in the Firecrawl request/runtime path.
• This feels related in class to SecretRef runtime/materialization bugs like [Bug]: SecretRef keys are re-materialized as plaintext in ~/.openclaw/agents/*/agent/models.json after runtime load #28359, though the symptom here is different:
  • not plaintext leakage
  • but incorrect runtime use of a SecretRef-backed credential

Suggested direction

Investigate whether the Firecrawl web-fetch provider/request path is receiving:

• the unresolved raw op://... string, or
• the wrong config snapshot/object,
  despite the gateway showing the field as resolved in runtime config views.