**Bug: GUI chat shows "Failed to get response" despite working API backend (Windows)**

[james1998stuart]

Description

Environment

• OS: Windows 11
• Desktop version: desktop-v1.0.2 (May 25, 2026)
• Model: qwen3.5:4b (via Ollama)

Describe the bug
The desktop GUI launches successfully — Inference Engine, AI Model, and API Server all show as Ready — but every chat message returns "Failed to get response." The backend API is fully functional.

Evidence that the backend works fine

Health check passes:

curl http://localhost:8000/health
# Returns: {"status":"ok"}

Chat completions work via curl:

Invoke-WebRequest -Uri "http://localhost:8000/v1/chat/completions" -Method POST -ContentType "application/json" -Body '{"model":"qwen3.5:4b","messages":[{"role":"user","content":"hello"}]}' -UseBasicParsing
# Returns a valid completion response

The CLI version (jarvis in terminal) also works correctly.

Conclusion
The issue appears to be isolated to the GUI layer — it is not correctly sending requests to or handling responses from the local API server on Windows.

Steps to Reproduce

Steps to reproduce

1. Install desktop-v1.0.2 on Windows
2. Launch openjarvis-desktop.exe
3. Wait for all three status indicators to show Ready
4. Type any message in the chat input and send

Expected Behavior

Expected behavior
Chat message gets a response from the model.

Actual Behavior

Actual behavior
GUI displays "Failed to get response" for every message.

Operating System

Windows

Python Version

3.11

Hardware

NVIDIA GPU

Engine

Ollama

Logs / Traceback

[jonsaadfalcon]

Thanks @james1998stuart — the side-by-side curl-vs-GUI evidence with all three status lights green is excellent triage data. That isolates the bug to the GUI frontend's chat-API call path (the Tauri shell is up, the backend works, the chat input → fetch → response handling is what breaks).

This isn't a regression from the recent desktop launcher fix (#437) — that fix lives in frontend/src-tauri/src/lib.rs and improved backend health-detection / stderr drainage, not the JS-side chat call. Your bug is in frontend/src/... (the React layer).

Likely candidates worth checking if you want to dig:

• The chat-page fetch target — is it hardcoded to a host/port that differs from where jarvis serve bound? Recent installer work on Windows defaults to 127.0.0.1:8000; if the GUI calls localhost:8000 and Windows resolves localhost to ::1 (IPv6) while jarvis serve only binds 127.0.0.1 (IPv4), you'd get a connection failure even though curl works.
• The error from `Failed to get response" — does opening DevTools (Ctrl+Shift+I in the Tauri window if dev mode is enabled, or the equivalent build for prod) show a network error in the Console / Network tab? That would pin it down in 5 minutes.

Not a regression but a real bug. Leaving open and pinging for ownership on the frontend side.

[selena731]

@james1998stuart do you still see this issue with the latest builds?