[Bug] No endpoints found that support image input” persists after removing images from prompt

[krxdow]

Version

Dive Desktop v0.14.1

Environment

Arch Linux desktop
Using OpenRouter as provider

Context

I am using text-only models (MiniMax M 2.5, Qwen 3 Next Thinking).

At first, I didn’t know these models do not support image inputs. I understand that now.

However, even after removing images from the prompt, the error still persists.

Problem

If I attach an image once and then delete it, all subsequent requests fail with:

Error code: 404
No endpoints found that support image input
Error code: 404 - {'error': {'message': 'No endpoints found that support image input', 'code': 404}}

This happens even when:

• the prompt contains only text
• the image is fully removed from the UI
• I paste/import a completely new text prompt

Expected behavior

After removing the image, Dive should send a text-only request and work normally with text-only models.

Actual behavior

Dive appears to still send an image or multimodal payload internally, which causes OpenRouter to route the request to a vision endpoint and return 404.

Steps to reproduce

1. Select a text-only model
2. Attach an image
3. Remove the image
4. Send a text-only prompt (or paste/import new text)
5. 404 error persists

Observations

• Creating a new chat sometimes fixes it
• Restarting and continuing the same conversation does NOT fix the issue
• The error persists in a loop for the conversation concerned
• Suggests cached conversation state or stale attachment data
• Likely an image field (image_url or similar) is still present in the request payload

Request

Please ensure that:

• removing an image fully clears it from the request payload
• the payload is rebuilt strictly as text-only when no image is present

This would prevent routing errors when using non-multimodal models.

[ckaznable]

@krxdow How do you delete images in chat?

[krxdow]

I added the image via the file upload icon, with my prompt, but when I got the error I wrote a new prompt without the image (still the same conversation).

[krxdow]

Resolution / Workaround

I experienced additional MCP-related issues beyond the original OAuth error.

Dive was not correctly applying configuration changes:

• MCP server modifications were ignored
• tools were not refreshed
• reconnect attempts kept using stale settings
• random initialization failures persisted

This suggested a local cache or corrupted state problem.

I performed a full reset by deleting the local Dive directory:

rm -rf ~/.dive

Then I reinstalled the package and reconfigured everything from scratch.

This removed all local settings and history, but it resolved the issues completely
If someone encounters similar behavior (config not updating, MCP not connecting, or inconsistent state), a clean reset of ~/.dive may fix the problem.