Summary

• Problem: Xiaomi MiMo mimo-v2-pro / mimo-v2-omni can return the user-visible final answer in reasoning_content, which OpenClaw currently surfaces as thinking instead of normal assistant text, so the reply can appear blank.
• Why it matters: affected Xiaomi users can get an empty-looking assistant response even though the model produced an answer.
• What changed: added a Xiaomi-only stream compatibility wrapper that converts reasoning-only final assistant messages into text for the affected MiMo models, and added regression tests for both the targeted and non-target Xiaomi paths.
• What did NOT change (scope boundary): this PR does not change the generic OpenAI-compatible parser, non-Xiaomi providers, auth flow, or model selection behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Xiaomi/MiMo models output to reasoning_content instead of content field openclaw/openclaw#60261
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: Xiaomi's OpenAI-compatible chat completions path can place the final answer in reasoning_content. The shared parser maps that to a thinking block, while downstream rendering expects user-visible output in text blocks.
• Missing detection / guardrail: there was no Xiaomi-specific compatibility layer or regression test for a final assistant message that contains reasoning only and no text.
• Prior context (git blame, prior PR, issue, or refactor if known): the shared OpenAI-compatible parsing behavior is reasonable for providers that use reasoning_content for actual reasoning output, but Xiaomi MiMo uses it for the final visible answer in this case.
• Why this regressed now: the issue surfaced once Xiaomi MiMo reasoning models were used through the standard openai-completions path without a provider-specific normalization step.
• If unknown, what was ruled out: this was not an auth, model-selection, or request-formatting problem; the content was returned by the provider but landed in the wrong content block type for rendering.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
• Unit test
• Seam / integration test
• End-to-end test
• Existing coverage already sufficient
• Target test or file: extensions/xiaomi/index.test.ts
• Scenario the test should lock in: reasoning-only final assistant messages from mimo-v2-pro / mimo-v2-omni are normalized into text, while non-target Xiaomi models remain unchanged.
• Why this is the smallest reliable guardrail: it exercises the actual Xiaomi provider registration + wrapStreamFn seam without needing live Xiaomi API traffic.
• Existing test that already covers this (if any): none
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Xiaomi MiMo mimo-v2-pro / mimo-v2-omni replies no longer appear blank when the provider returns the final answer via reasoning_content.
• Non-target Xiaomi models keep their existing behavior.
• Non-Xiaomi providers keep their existing behavior.

Diagram (if applicable)

Before:
[Xiaomi MiMo response]
  -> [final answer only in reasoning_content]
  -> [parsed as thinking only]
  -> [no normal assistant text rendered]

After:
[Xiaomi MiMo response]
  -> [Xiaomi-only compatibility wrapper]
  -> [reasoning-only final message normalized to text]
  -> [assistant reply rendered normally]