multimodal image forwarding seems to be broken (kimi k3 + claude code)

[LPFchan]

Client or integration

Claude Code

Area

Proxy and routing

Summary

test image:

prompt:

/Users/yeowool/Desktop/test.jpg
fetch this image from macbook air and describe it

assistant response:

It's the classic pink feather-winged pig clip art: a plump pink pig standing in profile with tiny cartoon wings on its back, plus a small pink wing icon in the bottom-left corner and the caption "Not Today" along the bottom — a "when pigs fly" joke image.

Reproduction

1. ocx claude
2. make the agent fetch image from remote sources
3. make the agent read and describe the image
4. watch the agent hallucinate out of thin air

Version

2.8.0

Operating system

macOS 15.7.4

Provider and model

kimicode/k3-256k

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[devuterian]

I am also experiencing this with OpenCodex on macOS.

In my case, I tried it through commandcode.io using deepseek-v4-pro. The image contained only the blue word “green” on a white background. The first response hallucinated an unrelated conversation and even included a local file path that was not present in the image. After I asked it to try again with GPT-5.6 Luna, it correctly read “green”.

This appears to be the same multimodal image-forwarding issue described here.

[lidge-jun]

Triage: confirmed still present on dev — openai-chat.ts:227 flattens tool-result parts through contentPartsToText, which replaces images with the literal [image]. PR #912 is the correct fix shape (re-send image parts in a user vision message after the tool round, matching the Google/Kiro adapters); it is in the merge queue right behind #892.

[lidge-jun]

Fixed on dev by #912 (merge commit 1b620266b), authored by @DevMello.

What was happening. Chat Completions tool messages accept only strings or text parts, so an image inside a tool result had nowhere to go on the wire. openai-chat flattened the whole tool result through contentPartsToText, which is where the literal [image] you saw came from — and why the model then described an image it had never received.

The route, traced end to end for your kimicode/k3 + Claude Code case:

1. Claude Code sends an Anthropic tool_result carrying the image.
2. src/claude/inbound.ts:96-113 preserves it as input_image.
3. src/responses/parser.ts:547-555 converts it to an internal toolResult with structured image parts.
4. Both the Kimi OAuth preset (src/providers/registry.ts:712-741) and the API-key preset (:1428-1444) resolve to openai-chat.
5. That adapter flattened it.

The fix collects image parts while the tool round is consumed and flushes them as a following user message once the round closes — the same carrier shape google.ts and kiro.ts already use for the same reason.

On the second report in this thread (deepseek-v4-pro via commandcode.io): that is a different path and this fix does not cover it. Built-in DeepSeek V4 models are listed in noVisionModels (src/providers/registry.ts:1013-1016), so they route through the vision sidecar rather than direct image forwarding. A custom registry entry without equivalent capability metadata can reach the direct path instead. If you are still seeing it there after updating, please open a separate issue with your provider config — it is worth tracking on its own rather than under this one.

Verified before merge: typecheck clean on the merged tree, 42 image/EOF tests and 37 parser/vision tests passing, and a red-green ablation confirming four image-forwarding tests fail without the fix while the image-free control still passes.

Thanks for the report, and thanks @DevMello for the fix.