Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Environment

• OpenClaw: 2026.4.21 (f788c88)
• Node: v24.14.1
• OS: Windows 11
• Provider config: api: "anthropic-messages", baseUrl: "https://api.minimax.io/anthropic", apiKey from env (sk-cp- Coding Plan key)
• Model: MiniMax-M2.5 (returned model id: minimax-m2.5-20260211)

Symptom

~26% of cron-triggered sessions today crashed with this error on the very first model call:

Cannot read properties of undefined (reading 'type')

The assistant message recorded in the session jsonl shows:

• usage.input > 0 (request reached the provider)
• usage.output: 0
• content: []
• responseId populated (provider responded)
• stopReason: "error"

So the upstream API returned a response, but the OpenClaw anthropic-messages adapter rejected it before producing any usable output. Sessions exit with no work done.

Failure rate

4 of 15 cron sessions on 2026-05-01 (26%). Concentrated on early-no-op sessions where the model's response is likely a single thinking block that hits stop without ever opening a text block.

Suspected cause

MiniMax's Anthropic-compatible endpoint sometimes returns a response with content that contains only a thinking block (no text block) — particularly when reasoning consumes most of the token budget before stop fires. The streaming adapter at dist/anthropic-vertex-stream-CpkZd5Cl.js appears to handle the streaming events with optional chaining (good), but there may be a downstream consumer that assumes content[0]?.type === "text" and dereferences content[0].type directly when content is empty.

Candidate code paths I traced (without the source map I can't pin a line):

• Lines ~278–306 of the same file iterate msg.content and access block.type without guards while reconstructing wire-format messages for the next call. If the previous turn's content array is empty or sparse, this would explode.
• Possibly a non-streaming response finalizer that handles empty content arrays without a defensive default.

Steps to reproduce

1. Configure provider:

   "minimax-portal": {
     "baseUrl": "https://api.minimax.io/anthropic",
     "api": "anthropic-messages",
     "apiKey": { "source": "env", "id": "MINIMAX_API_KEY" },
     "models": [{ "id": "MiniMax-M2.5" }]
   }

2. Set agent primary to minimax-portal/MiniMax-M2.5.
3. Trigger a cron run with low max_tokens or a system prompt that elicits reasoning-heavy responses.
4. ~25% of runs crash with the above error.

A direct curl reproduces the response shape that likely triggers this — at low max_tokens, MiniMax returns content with only a thinking block:

curl -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -X POST https://api.minimax.io/anthropic/v1/messages \
  -d '{"model":"MiniMax-M2.5","messages":[{"role":"user","content":"Say OK"}],"max_tokens":50}'
# returns content: [{"thinking": "...", "type": "thinking"}], stop_reason: "max_tokens"

Production impact

Running two cron-driven editorial agents at 30-min cadence. ~26% session loss is significant — multiple cron firings per day produce zero work despite spending tokens on input. Workaround would be either (a) defensive default in the adapter when content has no text block, or (b) a fallback to surface the thinking content as text when no text block is present (not ideal but unblocks downstream consumers).

Expected behavior

Cron-driven sessions invoke the primary provider via the anthropic-messages adapter, receive a valid Anthropic-format response (one or more content blocks of type text, thinking, and/or tool_use), and produce usable output. When the model's response contains only a thinking block with no text block (e.g. when reasoning fills the token budget before a text block opens), the adapter should either (a) surface the thinking content as text, (b) emit an empty-text fallback, or (c) gracefully request a continuation — not throw an unhandled TypeError.

Actual behavior

Actual behavior

~26% of cron sessions on 2026-05-01 (4 of 15 sessions) crash on the very first model call with:

Cannot read properties of undefined (reading 'type')

The assistant message recorded in the session jsonl shows:

• usage.input > 0 (request reached the provider, e.g. 18,792 input tokens billed)
• usage.output: 0
• content: []
• responseId populated (provider DID respond — e.g. 0643a57dcd08914129019c18df11e3e1)
• stopReason: "error"

So the upstream returned a response, but the OpenClaw adapter rejected it before producing any usable output. Sessions exit with no work done. Token cost is incurred for input with zero deliverable result.

Suspected cause

MiniMax's Anthropic-compatible endpoint can return content with only a thinking block (no text block) — particularly when reasoning consumes most of the token budget before stop fires. The streaming adapter at dist/anthropic-vertex-stream-CpkZd5Cl.js handles content_block events with optional chaining (good), but there appears to be a downstream consumer that assumes a text block exists and dereferences content[0].type (or similar) directly.

Candidate code paths I traced:

• Lines ~278–306 of the same file iterate msg.content and access block.type without guards while reconstructing wire-format messages for the next call. If a previous turn's content array is empty or has only thinking, this could trip.
• A non-streaming response finalizer that may not defensively handle an empty content array.

OpenClaw version

2026.4.21 (f788c88)

Operating system

Windows 11 Pro 26200, Node v24.14.1

Install method

No response

Model

MiniMax-M2.5via OpenClaw provider idminimax-portal(returned model id from upstream:minimax-m2.5-20260211`, build date 2026-02-11)

Provider / routing chain

primary: minimax-portal/MiniMax-M2.5 (Anthropic-compatible endpoint at https://api.minimax.io/anthropic, sk-cp- Coding Plan key, api setting anthropic-messages) - fallback[0]: openrouter/minimax/minimax-m2.5 - fallback[1]: openrouter/minimax/minimax-m2.5:free - fallback[2]: google/gemini-3-flash - (further Gemini family + alternates after)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response