fix(auxiliary): support minimax-oauth as an auxiliary provider for vision

[raymondyan-zhijie]

Summary

resolve_provider_client's OAuth handling only covered nous / openai-codex / xai-oauth. A config using auxiliary.vision: {provider: minimax-oauth, model: MiniMax-M3} fell through to the "Other OAuth providers not directly supported" arm and returned (None, None), so check_vision_requirements() stayed false and the vision tool was permanently unavailable — images sent over Feishu/WeChat/Open WebUI returned 400.

This adds a dedicated minimax-oauth branch to resolve_provider_client and a _build_minimax_oauth_aux_client() helper that mirrors how agent_init.py constructs the main agent's MiniMax OAuth client.

Implementation notes

• MiniMax OAuth issues short-lived (~15 min) access tokens; the Anthropic SDK caches api_key as a static string at construction time, so a static bearer would 401 mid-session.
• build_minimax_oauth_token_provider() returns a callable; build_anthropic_client detects the callable and installs a per-request bearer hook that re-reads auth.json, so a refresh persisted by another process is picked up immediately.
• Falls back to (None, None) with a warning when no MiniMax OAuth token is present — never blocks on missing auth.
• Branch inserted between the xai-oauth branch and the Custom endpoint branch in resolve_provider_client.

Verification

• check_vision_requirements() gate returns True.
• resolve_vision_provider_client() resolves to an AsyncAnthropicAuxiliaryClient with model MiniMax-M3.
• Real vision call against a test image correctly identified its contents (product spec sheet with dimensions + QR code).
• Regression: xai-oauth with no token still returns (None, None).
• Verified on the operator's production host (gateway runs as the admin user) and confirmed via live Feishu image test.

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Duplicate of #36779: it already provides the dedicated MiniMax OAuth auxiliary routing for this same missing dispatch path.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(auxiliary): support minimax-oauth as an auxiliary provider for vision

1. AnthropicAuxiliaryClient(real_client, final_model, token_provider, base_url, is_oauth=False) — the session is OAuth-authenticated but is_oauth is passed as False. Verify what is_oauth controls in AnthropicAuxiliaryClient (e.g. refresh handling, error semantics) and confirm False doesn't disable the per-request token re-read that the docstring relies on; compare with _build_xai_oauth_aux_client's usage of the same flag.
2. final_model = model or "MiniMax-M3" hardcodes a default model name that bypasses the model catalog. If "MiniMax-M3" is not a known catalog id, _normalize_resolved_model(model or default, provider) may behave unexpectedly; consider resolving the default from config / provider profile like the other auxiliary builders.
3. The broad except Exception collapses every failure into (None, None), so a genuine wiring error (e.g. build_anthropic_client failing for a non-auth reason) is silently reported as "no token found" and only debug-logged. Distinguishing "not authenticated" from "build failed" in the warning would make misconfigurations much easier to diagnose.

[raymondyan-zhijie]

Rebased onto current main and re-pushed.

The revision that was here patched the inline provider if-chain inside resolve_provider_client. That chain was refactored into _EXPLICIT_PROVIDER_BRANCHES plus per-provider _resolve_*_branch helpers, and both hunk contexts from the old revision are gone from main — it could no longer be applied. The new revision adds _resolve_minimax_oauth_branch() and registers it in _EXPLICIT_PROVIDER_BRANCHES, matching the current router structure. Behaviour is unchanged from the original revision: +49 lines, one file, no effect on any other provider.

On the duplicate label. #36779 does target the same dispatch hole, but it has never been merged and reports DIRTY against main — it patches the same removed inline chain, so "already provides" doesn't hold. The two revisions are also not behaviourally equivalent: #36779 rewrites the base URL from /anthropic to /v1 and keeps a bare OpenAI client, whereas main pins this provider to the Anthropic Messages wire. The minimax plugin profile declares api_mode="anthropic_messages" with base_url="https://api.minimax.io/anthropic", and _prepare_aux_request converts image blocks to Anthropic format for _ANTHROPIC_COMPAT_PROVIDERS, which already includes minimax-oauth. Sending vision through /v1 would hand Anthropic-shaped image blocks to an OpenAI-wire endpoint.

Still true on main today:

_EXPLICIT_PROVIDER_BRANCHES: Dict[str, Callable[[_ResolveRequest], _ResolveResult]] = {
    "auto": _resolve_auto_branch,
    "openrouter": _resolve_openrouter_branch,
    "nous": _resolve_nous_branch,
    "openai-codex": _resolve_openai_codex_branch,
    "xai-oauth": _resolve_xai_oauth_branch,
    "custom": _resolve_custom_branch,
}

No minimax-oauth entry, so an auxiliary.vision.provider: minimax-oauth config falls through the generic OAuth arm and gets (None, None) — the client is never built and the vision aux task silently re-routes to a text-only fallback. Note the inconsistency: _ANTHROPIC_COMPAT_PROVIDERS already lists minimax-oauth, i.e. main treats it as an Anthropic-compatible endpoint for image conversion but cannot construct a client for it.

[alt-glitch]

This was generated by AI during triage.

Re-triaged after the rebase: dropping the duplicate label. #36779 targets the same dispatch hole but patches the pre-refactor inline chain and uses the /v1 OpenAI wire, while main routes minimax-oauth via Anthropic Messages (_ANTHROPIC_COMPAT_PROVIDERS) and _EXPLICIT_PROVIDER_BRANCHES still has no minimax-oauth entry. Tracking as related to #36779 / #38685 / #45241 instead.