Best possible solution:

Make one type-safe extractor cover every active tool-result replay path, including src/agents/openai-transport-stream.ts, then add redacted real behavior proof before merge.

Do we have a high-confidence way to reproduce the issue?

Yes from source: current provider and transport converters filter only text blocks and fall back to (see attached image) for structured non-text, non-image tool-result blocks. I did not run a live provider turn in this read-only review.

Is this the best way to solve the issue?

No. The helper direction is plausible, but this PR is not the best complete fix until it is type-safe, covers the active Responses transport path, and includes real behavior proof.

Full review comments:

• [P1] Make the extractor type-compatible — src/llm/providers/tool-result-text.ts:33
extractToolResultText takes Record<string, unknown>[], but the changed converters pass ToolResultMessage.content, which is typed as (TextContent | ImageContent)[]; CI reports TS2352 on all three changed source call sites. Make the helper accept readonly unknown[] and narrow internally, or use a compatible content-block type so the production code typechecks.
  Confidence: 0.95
• [P1] Use the real completions compat fixture — src/llm/providers/openai-completions.test.ts:1083
  The new test calls convertMessages(..., false), but the current signature expects a ResolvedOpenAICompletionsCompat object, so check-test-types fails with TS2345. Use the existing compat fixture/helper rather than a boolean placeholder.
  Confidence: 0.96
• [P1] Cover the active Responses transport path too — src/llm/providers/openai-responses-shared.ts:373
  This updates the provider-side Responses converter, but OpenAI Responses can also run through src/agents/openai-transport-stream.ts; that converter still filters only type: "text" blocks and falls back to (see attached image). The linked agent-context failure can therefore still happen on the native/managed transport path unless the helper is shared there or that path is proven unreachable for these blocks.
  Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.93

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 6830aa39eaa1.

Label justifications:

• P1: The linked bug can make a live agent unable to inspect ordinary tool output, breaking an active agent workflow.
• merge-risk: 🚨 message-delivery: The diff fixes some provider replay paths while an active OpenAI Responses transport path can still deliver structured tool results as (see attached image).
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists test commands but no redacted terminal output, logs, live output, recording, or linked artifact showing the fixed behavior in a real setup. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

PR surface:

Source +53, Tests +91. Total +144 across 7 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs src/llm/providers/openai-responses-shared.test.ts src/llm/providers/google-shared.convert.test.ts src/llm/providers/openai-completions.test.ts.
• [P1] node scripts/run-vitest.mjs <focused src/agents/openai-transport-stream test file>.
• [P1] Relevant TypeScript/check lane that covers the changed provider and test files.

What I checked:

• Live PR context: The PR closes Normal tool text outputs can degrade to “(see attached image)” placeholders in agent context #96857 and its body lists only a Vitest command, with no live output, terminal log, recording, or other after-fix real behavior proof. (63ecf452addc)
• Current provider failure mode: Current main builds OpenAI Responses tool output text by filtering only type: "text" blocks and falls back to (see attached image) when that text is empty, so a structured non-image block reproduces the reported failure by source inspection. (src/llm/providers/openai-responses-shared.ts:374, 6830aa39eaa1)
• Active sibling transport: OpenAI Responses models can route through createOpenAIResponsesTransportStreamFn, so the agent transport converter is an active sibling implementation for the same replay invariant. (src/agents/provider-transport-stream.ts:85, 6830aa39eaa1)
• Missing sibling fix: The active OpenAI Responses transport still filters only text blocks and falls back to (see attached image), while this PR only changes the provider-side converter. (src/agents/openai-transport-stream.ts:1273, 6830aa39eaa1)
• Typecheck failure evidence: CI logs show diff-caused TypeScript failures: the new helper signature rejects the typed ToolResultMessage.content call sites, the new completions test passes false where ResolvedOpenAICompletionsCompat is required, and the structured test fixture is not assignable to current Context. (src/llm/providers/tool-result-text.ts:33, 63ecf452addc)
• OpenAI dependency contract: OpenAI Node v6.39.1 allows Responses function-call output to be a string or a list of output content, so the intended text-output shape is compatible with the upstream SDK contract.

Likely related people:

• openclaw-clownfish[bot]: git blame attributes the current text-only tool-result conversions in both the provider and active transport paths to the same grafted commit. (role: introduced current implementation; confidence: medium; commits: ace22feb3fe2; files: src/llm/providers/openai-responses-shared.ts, src/agents/openai-transport-stream.ts)
• Ayaan Zaidi: git show records Ayaan Zaidi as the committer for the grafted commit that introduced the current provider and transport implementations in this checkout. (role: committer; confidence: medium; commits: ace22feb3fe2; files: src/llm/providers/openai-responses-shared.ts, src/agents/openai-transport-stream.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.