You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A single webp (or gif) image that is pulled into the conversation by the built-in Read image file tool makes every subsequent LLM request fail with a non-retryable 400 ... failed to decode image, and because the failed image stays in history and is re-sent on every turn, the session is permanently deadlocked — no prompt can ever make progress again.
The image MIME is sniffed correctly (image/webp / image/gif), so this is not a mislabeling bug. The kimi-for-coding endpoint simply rejects these formats, and kimi-code has no guard, no transcode, and no way to drop the offending image from context.
Environment
kimi-code 0.18.0 (observed). The 0.19.2 changelog does not appear to address the failed-image / history-resend path, but I have not re-verified on 0.19.2.
Model: kimi-for-coding (Kimi-k2.6)
macOS (arm64)
Driven headlessly by an ACP client in --yolo mode (non-interactive), though the same mechanism applies to any harness.
What happens
The agent, during a normal task, calls the built-in Read image file tool on a local asset that happens to be a webp (saved with a misleading .png filename) and a small gif:
From that point on, every turn fails immediately with the identical error:
turn failed turnId=2 (step 2.26, when the image entered context)
turn failed turnId=3
turn failed turnId=4
turn failed turnId=5 (sending "?" — anything — just triggers another doomed request)
The conversation contained 28 images total; 23 PNG + 2 JPEG decoded fine. The only failing inputs were 2 GIF + 1 WebP, all of them sniffed and labeled correctly as image/gif / image/webp.
Root cause (two compounding problems)
No format guard before sending to the vision endpoint. The Read-image tool forwards image/webp and image/gif to kimi-for-coding, which returns 400 failed to decode image. (Note: the general Kimi Vision docs list webp/gif as supported, but kimi-for-coding clearly does not accept them — an inconsistency worth confirming on the server side. Either way, kimi-code should transcode to png/jpeg, or refuse to attach, instead of poisoning the turn.)
A non-retryable image error permanently wedges the session. Because the failed image remains in history and is re-sent on every following request, turns 3/4/5/... can never succeed — there is no recovery short of starting a brand-new session or hand-editing wire.jsonl. This is the same family as #2279 (historical images re-sent) and Pasted images fail on text-only models — should offload to file + MCP path #905 (no offload fallback), but here it is triggered by the built-in Read-image tool on a server-rejected format, not by a text-only model or a web-session restore.
Expected behavior
Any one of these would break the deadlock:
Before attaching, check the active model's accepted formats and transcode webp/gif → png/jpeg (or downscale) when needed.
If the endpoint returns a non-retryable image-decode 400, drop the offending image from context (replace with a text note like [image omitted: unsupported format]) and let the turn proceed, instead of re-sending it forever.
Surface the failure to the user/harness as a recoverable condition rather than an infinite identical-error loop.
Steps to reproduce
Put a .png-named file that is actually webp bytes (any web-downloaded webp) in the working dir, plus a small .gif.
Ask the agent to read/analyze those images with kimi-for-coding as the model.
Observe the 400 failed to decode image (non-retryable).
Send any further message → it fails immediately with the same error. The session never recovers.
Summary
A single
webp(orgif) image that is pulled into the conversation by the built-in Read image file tool makes every subsequent LLM request fail with a non-retryable400 ... failed to decode image, and because the failed image stays in history and is re-sent on every turn, the session is permanently deadlocked — no prompt can ever make progress again.The image MIME is sniffed correctly (
image/webp/image/gif), so this is not a mislabeling bug. Thekimi-for-codingendpoint simply rejects these formats, and kimi-code has no guard, no transcode, and no way to drop the offending image from context.Environment
0.19.2changelog does not appear to address the failed-image / history-resend path, but I have not re-verified on 0.19.2.kimi-for-coding(Kimi-k2.6)--yolomode (non-interactive), though the same mechanism applies to any harness.What happens
The agent, during a normal task, calls the built-in Read image file tool on a local asset that happens to be a webp (saved with a misleading
.pngfilename) and a small gif:The very next LLM request fails:
From that point on, every turn fails immediately with the identical error:
The conversation contained 28 images total; 23 PNG + 2 JPEG decoded fine. The only failing inputs were 2 GIF + 1 WebP, all of them sniffed and labeled correctly as
image/gif/image/webp.Root cause (two compounding problems)
No format guard before sending to the vision endpoint. The Read-image tool forwards
image/webpandimage/giftokimi-for-coding, which returns400 failed to decode image. (Note: the general Kimi Vision docs list webp/gif as supported, butkimi-for-codingclearly does not accept them — an inconsistency worth confirming on the server side. Either way, kimi-code should transcode to png/jpeg, or refuse to attach, instead of poisoning the turn.)A non-retryable image error permanently wedges the session. Because the failed image remains in history and is re-sent on every following request, turns 3/4/5/... can never succeed — there is no recovery short of starting a brand-new session or hand-editing
wire.jsonl. This is the same family as #2279 (historical images re-sent) and Pasted images fail on text-only models — should offload to file + MCP path #905 (no offload fallback), but here it is triggered by the built-in Read-image tool on a server-rejected format, not by a text-only model or a web-session restore.Expected behavior
Any one of these would break the deadlock:
[image omitted: unsupported format]) and let the turn proceed, instead of re-sending it forever.Steps to reproduce
.png-named file that is actually webp bytes (any web-downloaded webp) in the working dir, plus a small.gif.kimi-for-codingas the model.400 failed to decode image(non-retryable).Related