count not forwarded to the API request

params.count is resolved and passed to runMiniMaxSearch, but the POST body only ever sends { q: params.query }. The result set is then trimmed client-side with .slice(0, params.count).

If the MiniMax Coding Plan API supports a result-count parameter (e.g. num or n), not forwarding it means the API always returns its default page size. When the user requests more results than the API default, the slice will silently under-deliver without any error.

Consider adding num: params.count (or whatever the API field is called) to the request body so the API is asked for the right number of results upfront.

This is a comment left during a code review.
Path: extensions/minimax/src/minimax-web-search-provider.ts
Line: 88-93

Comment:
**`count` not forwarded to the API request**

`params.count` is resolved and passed to `runMiniMaxSearch`, but the `POST` body only ever sends `{ q: params.query }`. The result set is then trimmed client-side with `.slice(0, params.count)`.

If the MiniMax Coding Plan API supports a result-count parameter (e.g. `num` or `n`), not forwarding it means the API always returns its default page size. When the user requests more results than the API default, the slice will silently under-deliver without any error.

Consider adding `num: params.count` (or whatever the API field is called) to the request body so the API is asked for the right number of results upfront.

How can I resolve this? If you propose a fix, please make it concise.

Cache key missing endpoint (region)

The cache key only includes ["minimax", query, resolvedCount] but omits the endpoint. Because the endpoint differs between global and CN regions, two separate configurations with the same query and count will collide on the same cache entry — a global-region result would be returned for a CN-region request (and vice versa).

Kimi's implementation shows the pattern: it includes baseUrl in the cache key to prevent exactly this kind of cross-region collision. The fix is to add endpoint as a component:

buildSearchCacheKey(["minimax", endpoint, query, resolvedCount])

This is a comment left during a code review.
Path: extensions/minimax/src/minimax-web-search-provider.ts
Line: 173

Comment:
**Cache key missing `endpoint` (region)**

The cache key only includes `["minimax", query, resolvedCount]` but omits the `endpoint`. Because the endpoint differs between global and CN regions, two separate configurations with the same query and count will collide on the same cache entry — a global-region result would be returned for a CN-region request (and vice versa).

Kimi's implementation shows the pattern: it includes `baseUrl` in the cache key to prevent exactly this kind of cross-region collision. The fix is to add `endpoint` as a component:

```
buildSearchCacheKey(["minimax", endpoint, query, resolvedCount])
```

How can I resolve this? If you propose a fix, please make it concise.

bundledWebSearchPluginRegistrations now includes the minimax plugin, but src/plugins/bundled-web-search-ids.ts (and the metadata tests that assert alignment) still omit minimax. This will break the “fast-path ids aligned with the registry” invariant and can cause resolveBundledWebSearchPluginIds to keep excluding the new bundled provider. Add minimax to BUNDLED_WEB_SEARCH_PLUGIN_IDS and update the expected bundled id lists accordingly.

The search cache key doesn’t include the resolved endpoint/region. If a user switches between Global and CN endpoints (or if different configs run in the same process), cached results can be served for the wrong region. Include endpoint (or the region string) as part of buildSearchCacheKey inputs.

The missing-credential message only mentions MINIMAX_API_KEY, but this provider also supports MINIMAX_CODE_PLAN_KEY (and advertises both in envVars). Update the guidance so users can resolve auth using either env var (and/or point at the configured secret path, consistent with other providers).

This new provider introduces non-trivial logic (endpoint selection, response mapping, related-search extraction, caching). Other bundled web search providers typically include a small *.test.ts plus an exported __testing surface for deterministic unit tests. Add at least a couple of unit tests for endpoint resolution (Global vs CN) and for mapping/extracting results from a representative API response shape.

The bundled provider-id map now includes minimax, but the alignment test in src/plugins/bundled-web-search.test.ts doesn’t assert the minimax mapping. Add a corresponding expectation there so future edits don’t accidentally break this new compat id.

Store MiniMax web key in a schema-valid config path

This writes the credential into plugins.entries.minimax.config.webSearch.apiKey, but the MiniMax plugin manifest currently defines configSchema as an empty object with additionalProperties: false (extensions/minimax/openclaw.plugin.json), so config.webSearch is invalid for that plugin. In practice, configuring MiniMax search via onboarding/configure will produce a plugin-schema validation error instead of persisting the key (unless users only rely on environment variables).

Useful? React with 👍 / 👎.

Include endpoint/region in MiniMax search cache key

The cache key omits endpoint/region even though requests are routed to either global or CN endpoint based on searchConfig.minimax.region. If region changes (or different sessions in one process use different regions), cached results from one endpoint can be served for the other until TTL expiry, returning stale/wrong-region data. The key should include endpoint (or normalized region) to avoid cross-region cache collisions.

Useful? React with 👍 / 👎.

Derive MiniMax search endpoint from configured CN base URL

resolveMiniMaxEndpoint only reads tools.web.search.minimax.region, so MiniMax web search defaults to the global host unless that legacy field is manually set. In the normal CN onboarding path (applyMinimaxApiConfigCn in extensions/minimax/onboard.ts), only models.providers.minimax.baseUrl is set, and the new plugin schema here only persists webSearch.apiKey, not region; as a result, users who chose the CN provider can still have web_search sent to api.minimax.io and fail in CN-only/auth-scoped environments.

Useful? React with 👍 / 👎.

Accept SecretRef objects for MiniMax web search key

The new MiniMax plugin schema only allows webSearch.apiKey to be a string, but OpenClaw’s secret-ref flow stores credentials as objects (for example when secret-input-mode=ref is used). That means valid MiniMax web-search credential configs are rejected as invalid config at load/validation time, so users cannot persist MiniMax search credentials in SecretRef mode even though every other bundled web-search provider accepts "string" | "object" for this field.

Useful? React with 👍 / 👎.

Infer MiniMax region from OAuth provider base URL too

Region inference only reads models.providers.minimax.baseUrl, so it misses CN OAuth setups where the configured base URL lives under models.providers.minimax-portal. In that common CN OAuth path, resolveMiniMaxRegion falls back to global, causing web search calls to target api.minimax.io instead of the CN endpoint unless users manually set tools.web.search.minimax.region.

Useful? React with 👍 / 👎.

Prefer MINIMAX_CODE_PLAN_KEY before MINIMAX_API_KEY

Credential fallback checks envVars in declaration order, so this provider currently picks MINIMAX_API_KEY first when both variables are set. For MiniMax coding-plan endpoints, that can make web_search fail with auth errors even though a valid MINIMAX_CODE_PLAN_KEY is present; elsewhere in the repo MiniMax auth already prefers code-plan first (src/infra/provider-usage.auth.ts). Reordering to prioritize MINIMAX_CODE_PLAN_KEY (and keeping resolution order consistent) avoids selecting the wrong credential in mixed-key environments.

Useful? React with 👍 / 👎.

Wrap related search suggestions before returning

The provider marks the payload as externalContent.wrapped: true, but related_searches strings are copied through without wrapWebContent. If MiniMax returns attacker-controlled suggestion text, that unwrapped content is passed directly to the model despite the wrapped flag, weakening the prompt-injection guardrail used for other web-search text fields. Wrap each related-search string (or omit the field) before adding it to the tool result.

Useful? React with 👍 / 👎.

Persist MiniMax region override in schema-backed config

resolveMiniMaxRegion now checks tools.web.search.minimax.region, but this plugin schema only allows plugins.entries.minimax.config.webSearch.apiKey and does not provide any persisted region field. In validated configs, object-valued tools.web.search.<provider> entries are normalized away unless they are in the legacy provider map, so minimax.region cannot reliably survive load/validation. That makes the explicit CN/global override path effectively unusable when endpoint inference from base URL is wrong or unavailable.

Useful? React with 👍 / 👎.

Add MiniMax web-search secret target to registry

Registering MiniMax as a bundled web-search provider here adds a new credential path (plugins.entries.minimax.config.webSearch.apiKey), but that path is not added to src/secrets/target-registry-data.ts; as a result, secret-registry consumers in src/secrets/target-registry-query.ts (for discovery/known-target checks used by openclaw secret plan/configure/audit flows) will not recognize or process MiniMax web-search SecretRefs. This leaves the new provider’s configured key unmanaged by the standard secret tooling.

Useful? React with 👍 / 👎.

Prefer scoped MiniMax key over legacy top-level apiKey

resolveMiniMaxApiKey reads searchConfig.apiKey first, which is the shared legacy tools.web.search.apiKey slot, before checking MiniMax env vars. If a user previously configured another provider that populated this legacy field (for example Brave) and later switches to MiniMax while relying on MINIMAX_CODE_PLAN_KEY/MINIMAX_CODING_API_KEY, the stale shared key wins and MiniMax requests are sent with the wrong credential, causing auth failures until the old top-level key is manually removed.

Useful? React with 👍 / 👎.