Summary

• Problem: After the first assistant turn in a session, every subsequent QQ-bot reply failed with ⚠️ Something went wrong while processing your request. Gateway logs showed OpenRouter returning HTTP 500 for the second and later requests, regardless of which model was selected (z-ai/glm-5.1, glm-5v-turbo, deepseek-v4-flash all reproduced).
• Why it matters: A single successful turn permanently poisons the session — every replay request carries the prior assistant message, so the bot is effectively unusable after one round. The 500 looks like an upstream outage and is hard to diagnose.
• What changed: In buildOpenAICompletionsParams, after convertMessages and injectToolCallThoughtSignatures, walk the outgoing message list and delete reasoning_details, reasoning_content, and reasoning from any assistant message before it hits the wire.
• What did NOT change (scope boundary): No change to the Anthropic Messages path, the OpenAI Responses path, the QQBot extension, transcript persistence, or transport-message-transform.ts. Only the Chat Completions request builder is affected. User messages are untouched.

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 #
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: QQ bot replies with the generic external-run-failure text starting from the second turn of any session; gateway logs show repeated HTTP 500 from OpenRouter on the Completions endpoint.
• Real environment tested: Local OpenClaw gateway on Linux, QQBot extension connected to a live QQ group, OpenRouter as the provider (routes hit AtlasCloud / Novita / Parasail).
• Exact steps or command run after this patch:
  1. pnpm build and restart gateway.
  2. Send a message in QQ → bot replies normally.
  3. Send a second message in the same session → bot replies normally (this is the previously broken turn).
  4. Continue multi-turn for ~5 messages to confirm the failure mode does not return.
• Evidence after fix: QQ chat now returns successive replies (e.g. cold-joke prompt followed by a second prompt both return real model output instead of the warning text). Gateway log no longer shows status=500 from OpenRouter; prompt.submitted events succeed back-to-back.
• Observed result after fix: Every turn in the session produces a real reply; no recurrence of the warning across multiple sessions and multiple models.
• What was not tested: Anthropic Messages path, the OpenAI Responses path, and providers that natively echo reasoning_details and expect them on input (none known).
• Before evidence (optional but encouraged): Captured request body that triggered the 500 saved as /tmp/openclaw-bad-request-latest.json (84 KB); replaying it via curl to OpenRouter reproduced the 500. Removing only the reasoning_details field flipped the same request to 200.

Root Cause (if applicable)

• Root cause: OpenRouter (and several other OpenAI-Completions-compatible providers) echo reasoning_details (array) and reasoning_content (string) inside response choices[].message to expose the model's chain of thought. Downstream message builders preserved those fields when the assistant turn was persisted into the conversation history. On the next turn, convertMessages (pi-ai) serialized the assistant message back into the request body verbatim, so the request now carried e.g. "reasoning_details": "<stringified array echo>". The Chat Completions input schema does not accept this field, and OpenRouter responds with a generic HTTP 500 instead of a 4xx parse error — which is why this looked like an upstream outage rather than a client-side bug.
• Missing detection / guardrail: There was no last-mile sanitizer between convertMessages and the wire to drop response-only fields from input messages. We had stripCompletionMessagesToRoleContent for strictMessageKeys providers, but the default path let anything through.
• Contributing context (if known): The error was non-deterministic in appearance — the first turn always worked because the history contained only a user message; the failure surfaced from the second turn onward, which made it look like a transient or rate-limit issue. Switching models did not help because the offending field came from our own request body, not the provider.

How the reproducing curl was produced

To rule out a transport bug vs. a body bug, I added temporary instrumentation in src/agents/provider-transport-fetch.ts that wrote every outgoing request body to /tmp/openclaw-bad-request-latest.json along with status, headers, and the response body. After triggering one bad turn from QQ, that file held the exact JSON body the gateway had POSTed.

I then replayed it as-is:

export OPENROUTER_API_KEY=sk-or-v1-...   # replace with your own key

# BAD: assistant message carries `reasoning_details` (string) -> reproduces HTTP 500
curl -sS -o /dev/null -w 'BAD  -> %{http_code}\n' \
  https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "deepseek/deepseek-v4-flash",
    "stream": false,
    "messages": [
      {"role":"user","content":"hello"},
      {"role":"assistant","content":null,
       "reasoning_details":"The user said hello. I should greet back.",
       "tool_calls":[{"id":"call_demo_1","type":"function",
                      "function":{"name":"noop","arguments":"{}"}}]},
      {"role":"tool","tool_call_id":"call_demo_1","content":"{\"ok\":true}"},
      {"role":"user","content":"say one more thing"}
    ]
  }'

# GOOD: same conversation with `reasoning_details` removed -> returns 200
curl -sS -o /dev/null -w 'GOOD -> %{http_code}\n' \
  https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "deepseek/deepseek-v4-flash",
    "stream": false,
    "messages": [
      {"role":"user","content":"hello"},
      {"role":"assistant","content":null,
       "tool_calls":[{"id":"call_demo_1","type":"function",
                      "function":{"name":"noop","arguments":"{}"}}]},
      {"role":"tool","tool_call_id":"call_demo_1","content":"{\"ok\":true}"},
      {"role":"user","content":"say one more thing"}
    ]
  }'

Then I ran a binary search over the message list / fields:

• Drop messages[2] (the assistant turn with the echoed reasoning) → 200.
• Keep messages[2] but remove reasoning_details only → 200.
• Keep messages[2] but coerce reasoning_details from a string back to its original array shape → 200.
• Keep only reasoning_details (string) and a minimal user turn → 500.

That isolated reasoning_details (as a stringified echo) as the sole trigger, and was the basis for the strip list (reasoning_details, reasoning_content, reasoning). The instrumentation was reverted; only the sanitizer ships.

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: src/agents/openai-transport-stream.test.ts — new describe("buildOpenAICompletionsParams strips response-only reasoning fields") block (2 cases).
• Scenario the test should lock in:
  1. An assistant message that carries reasoning_details / reasoning_content / reasoning (any of the three) must produce a request whose corresponding message has none of those fields.
  2. The same fields on a user message must be left alone (they are user input, not response echo).
• Why this is the smallest reliable guardrail: The defect lives entirely in the request-builder path; a unit test on buildOpenAICompletionsParams exercises it deterministically without needing a network or a live provider. Higher-level tests would only flake or require provider mocks.
• Existing test that already covers this: None.
• If no new test is added, why not: N/A — tests are added.

User-visible / Behavior Changes

QQ-bot (and any other channel that hits the OpenAI Completions transport) no longer fails with ⚠️ Something went wrong … from the second turn onward. No config or default change.

Diagram (if applicable)

Before:
[turn 1] user -> request OK -> assistant reply (with reasoning_details echo persisted)
[turn 2] user + assistant(turn1, with reasoning_details) -> OpenRouter 500 -> warning text in QQ

After:
[turn 1] user -> request OK -> assistant reply (with reasoning_details echo persisted)
[turn 2] user + assistant(turn1) -> [strip reasoning_* on assistant] -> OpenRouter 200 -> real reply

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (same endpoint, same auth, payload only loses three fields).
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Local Node gateway, QQBot extension
• Model/provider: OpenRouter (verified across z-ai/glm-5.1, glm-5v-turbo, deepseek-v4-flash; routed via AtlasCloud / Novita / Parasail)
• Integration/channel (if any): QQBot
• Relevant config (redacted): default OpenAI-Completions transport, no strictMessageKeys override

Steps

1. Start a QQ session with the bot, send any message — succeeds.
2. Send a second message in the same session — previously failed with the warning text, now succeeds.
3. Repeat several turns and across model switches.

Expected

• Each turn returns a real model reply.

Actual

• Each turn returns a real model reply; gateway no longer logs OpenRouter 500.

Evidence

• Failing test/log before + passing after (captured request body + curl replay before; passing unit tests after).
• Trace/log snippets (gateway 500 logs before; clean prompt.submitted after).
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • Two-plus consecutive QQ turns in the same session.
  • curl replay of the captured request body before vs. after stripping reasoning_details (500 → 200).
  • New unit tests pass.
• Edge cases checked:
  • User messages carrying the same field names are not modified.
  • Assistant messages without any reasoning field are not modified.
  • Both string and array shapes of reasoning_details are handled (we delete the field outright).
• What I did not verify:
  • Anthropic Messages path and OpenAI Responses path (out of scope; not affected by the change).
  • Providers that hypothetically require reasoning_details as input (none known).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: A future provider may legitimately accept reasoning_details on input as part of a thought-replay protocol; stripping would silently lose context.
  • Mitigation: The strip is scoped to the OpenAI Chat Completions request builder only, not the Anthropic or Responses paths. If such a provider appears, the strip can be gated on the provider compat profile (the same place strictMessageKeys is wired). Documented in the inline comment above the strip function.
• Risk: Different provider echoes a different response-only field name we didn't list.
  • Mitigation: The list is centralized in COMPLETIONS_RESPONSE_ONLY_MESSAGE_FIELDS; adding a name is a one-line change. The proper long-term fix is to make pi-ai's convertMessages drop these at the serializer level.