openclaw - 💡(How to fix) Fix [Bug]: Gateway Zod validator rejects plugin-specific config fields in plugins.entries.*.config — affects OpenViking multi-tenant integration [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Gateway Zod validator rejects plugin-specific fields (mode/accountId/userId) in plugins.entries.*.config, creating a deadlock with OpenViking multi-tenant auth which requires those fields to send tenant headers.

Steps to reproduce

1. Configure OpenViking Docker with root_api_key in ov.conf
2. In openclaw.json, add plugins.entries.openviking.config with fields beyond baseUrl/apiKey: { "config": { "baseUrl": "http://127.0.0.1:1933", "apiKey": "...", "mode": "remote", "accountId": "evelyn-main", "userId": "user" } }
3. Run: openclaw config validate
4. Observe: "must NOT have additional properties: mode, accountId, userId"
5. Remove those fields → Gateway starts, but OpenViking server rejects with: "INVALID_ARGUMENT: ROOT requests to tenant-scoped APIs must include X-OpenViking-Account and X-OpenViking-User headers"

Expected behavior

Plugin-specific config fields declared by a plugin's configSchema should be accepted by the gateway validator. The gateway should delegate validation to each plugin's own schema instead of applying a global "additionalProperties: false" rule to all plugins.entries.*.config blocks.

Actual behavior

The gateway-level Zod validator treats plugin-specific fields (mode, accountId, userId) as "additional properties" and rejects the config before the plugin ever loads. This forces users to remove tenant-identifying fields, which then causes the OpenViking server to reject all data API calls as unauthorized ROOT requests.

OpenClaw version

2026.5.3-1 (2eae30e)

Operating system

Ubuntu 24.04 LTS

Install method

npm global (via nvm)

Model

minimax-portal/MiniMax-M2.7-highspeed

Provider / routing chain

openclaw gateway → minimax-portal (MiniMax OAuth CN)

Additional provider/model setup details

Not relevant to this bug. The issue is in gateway config validation, not model routing.

Logs, screenshots, and evidence

=== Validation Error ===
$ openclaw config validate
Config invalid: must NOT have additional properties: mode, accountId, userId

=== OpenViking ROOT Error (after removing those fields) ===
OpenViking request failed [INVALID_ARGUMENT]: ROOT requests to tenant-scoped APIs must include X-OpenViking-Account and X-OpenViking-User headers. Use a user key for regular data access.

=== Verified Workaround ===
Using a User Key (generated via OpenViking Admin API) instead of Root Key allows OpenViking to auto-resolve tenant identity without headers. Minimal working config:
{
  "openviking": {
    "enabled": true,
    "config": {
      "baseUrl": "http://127.0.0.1:1933",
      "apiKey": "<user-key>"
    }
  }
}
Result: openviking: registered context-engine — no ROOT errors.

Impact and severity

• Affected: All users trying to integrate OpenViking with OpenClaw in multi-tenant mode
• Severity: High — blocks OpenViking memory plugin from working with proper tenant isolation
• Frequency: 100% reproducible when plugin-specific config fields are needed
• Consequence: Users must either (a) disable tenant isolation or (b) use the User Key workaround which is undocumented and requires Admin API calls

Additional information

Related issues:

• OpenClaw #49495 — Zod validation bottleneck for plugin configs (same root cause)
• OpenViking #1216 — accountId/userId forwarding for OpenClaw plugin
• PR #49648 — "fix: allow plugin apiKey and env in gateway config validator" (unmerged)

Also filed companion issue in OpenViking repo for documentation improvement: https://github.com/volcengine/OpenViking/issues/1960