Bug type

Regression (worked before, now fails)

Summary

x_search fails on current April builds even when xAI auth is configured at the canonical plugin-owned path.

On our current setup, the built-in x_search tool returns:

{
  "status": "error",
  "tool": "x_search",
  "error": "plugins.entries.xai.config.webSearch.apiKey: unresolved SecretRef \"exec:onepassword_xai:value\". Resolve this command against an active gateway runtime snapshot before reading it."
}

This worked for us prior to the April xAI config/auth refactors.

Steps to reproduce

1. Configure xAI auth at the canonical path:
   • plugins.entries.xai.config.webSearch.apiKey
2. Store that key as an exec SecretRef (in our case via 1Password).
3. Enable x_search.
4. Invoke the built-in x_search tool.

Our relevant config shape is:

{
  "tools": {
    "web": {
      "search": {
        "provider": "brave"
      },
      "x_search": {
        "enabled": true,
        "model": "grok-4-1-fast-non-reasoning",
        "maxTurns": 2,
        "timeoutSeconds": 30,
        "cacheTtlMinutes": 15
      }
    }
  },
  "plugins": {
    "entries": {
      "xai": {
        "config": {
          "webSearch": {
            "apiKey": {
              "source": "exec",
              "provider": "onepassword_xai",
              "id": "value"
            }
          }
        }
      }
    }
  }
}

Expected behavior

x_search should resolve the xAI credential from the active runtime snapshot and run successfully.

It should not matter that normal web_search is currently using another provider (brave).

Actual behavior

x_search fails immediately with:

plugins.entries.xai.config.webSearch.apiKey: unresolved SecretRef "exec:onepassword_xai:value". Resolve this command against an active gateway runtime snapshot before reading it.

OpenClaw version

2026.4.10 (44e5b62)

Operating system

macOS 25.3.0 (arm64)

Install method

global npm install / local gateway service

Model

N/A for the failing tool call itself

Provider / routing chain

Built-in x_search tool

Additional provider/model setup details

• tools.web.search.provider is brave
• xAI auth is present only at the canonical plugin-owned path plugins.entries.xai.config.webSearch.apiKey
• that xAI auth is an exec SecretRef

Logs, screenshots, and evidence

Direct runtime reproduction from the tool surface:

{
  "status": "error",
  "tool": "x_search",
  "error": "plugins.entries.xai.config.webSearch.apiKey: unresolved SecretRef \"exec:onepassword_xai:value\". Resolve this command against an active gateway runtime snapshot before reading it."
}

Related upstream context that looks relevant:

• #54555 - missing_xai_api_key even if filled in config
• #59674 - moved x_search config behind the xAI plugin boundary
• #59691 - made x_search auth plugin-owned
• broader unresolved SecretRef/runtime snapshot issues also seem adjacent: #50161, #51263, #57272

Impact and severity

Affected: likely anyone using x_search with canonical plugin-owned xAI auth stored as an exec SecretRef
Severity: medium-high

Additional information

My current suspicion is an April regression/edge case in the xAI auth/runtime-secret path:

• pre-April this worked for us
• after the April xAI refactors, x_search now depends on plugin-owned xAI auth
• when that auth is an exec SecretRef, the runtime path appears to treat it as unresolved/inactive for x_search

This may be related to the broader runtime snapshot / unresolved SecretRef bugs, but this report is specifically about the current x_search surface failing with the canonical xAI auth path.