feat: simplify connection status check for Ollama and LM Studio

[devin-ai-integration]

feat: simplify connection status check for Ollama and LM Studio

Summary

Re-implements the feature from #2968 (which was reverted) with a simpler approach. Shows connection status for local LLM providers (Ollama, LM Studio) in AI settings.

Key simplifications vs #2968:

• 1 new file instead of 2 — merged connection check + hook into a single use-local-provider-status.ts (67 lines vs original 122)
• No Effect.js for connection check — uses plain fetch + AbortController for 2s timeout
• No LMStudio SDK for connection check — pings the OpenAI-compatible /v1/models endpoint (works for both providers)
• No changes to useConfiguredMapping — status logic stays in the rendering layer, avoiding the complex eligibility bypass logic from the original

Features (same as original):

• Status badge on provider cards (Connected / Not Running / spinner)
• "Connect" button when provider is not running (triggers manual recheck)
• Green dot indicator in provider dropdown when connected
• Local providers disabled in dropdown when not connected
• Download and model library links for Ollama and LM Studio

Review & Testing Checklist for Human

• Verify /v1/models endpoint works for both providers: The original used Ollama's /api/tags and LMStudio's WebSocket SDK. This simplified version pings ${baseUrl}/models for both. Confirm Ollama responds correctly on http://127.0.0.1:11434/v1/models and LM Studio on http://127.0.0.1:1234/v1/models
• Test with Ollama running/stopped: Start Ollama, open AI settings → verify "Connected" badge. Stop Ollama → verify "Not Running" appears (up to 15s)
• Test with LM Studio running/stopped: Same as above
• Test "Connect" button: When showing "Not Running", click Connect and verify it triggers a status recheck
• Verify provider dropdown behavior: Local providers should be disabled when not running, show green dot when connected, and other providers should be unaffected
• Check accordion trigger layout: The status badge and Connect button shouldn't break the layout of non-local provider cards

Notes

• This was not tested in a running Tauri desktop environment — human testing with actual Ollama/LM Studio is essential
• The useLocalProviderStatus hook is called for every provider via NonHyprProviderCard, but the enabled: isLocal flag prevents actual network requests for non-local providers

Link to Devin run: https://app.devin.ai/sessions/853696731f4448a4a1633f12ddd7f8b1
Requested by: @ComputelessComputer

---

[netlify]

✅ Deploy Preview for hyprnote canceled.

Name	Link
🔨 Latest commit	589f3b1
🔍 Latest deploy log	https://app.netlify.com/projects/hyprnote/deploys/698bfffcc6082700080019ab

[netlify]

✅ Deploy Preview for hyprnote-storybook canceled.

Name	Link
🔨 Latest commit	589f3b1
🔍 Latest deploy log	https://app.netlify.com/projects/hyprnote-storybook/deploys/698bfffc83bed9000807a4a1

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 8 additional findings in Devin Review.

[devin-ai-integration]

🟡 query.isLoading is false on refetch, so "Connect" button never shows loading feedback

When the user clicks the "Connect" button to recheck a local provider's status, there is no visual feedback because the "checking" state is derived from query.isLoading, which is only true on the initial fetch when no cached data exists.

Root Cause

In React Query, isLoading is true only when isPending && isFetching — i.e., there's no cached data and a fetch is in progress. After the first connection check fails (query.data = false), subsequent refetches (triggered by the "Connect" button via query.refetch()) set isFetching = true but keep isLoading = false because cached data (false) already exists.

The status derivation at use-local-provider-status.ts:59-63:

const status: LocalProviderStatus = query.isLoading
  ? "checking"
  : query.data
    ? "connected"
    : "disconnected";

After the first failed check, clicking "Connect" triggers refetchStatus() → query.refetch(). During this refetch:

• query.isLoading is false (cached data exists)
• query.data is false (cached failed result)
• So status stays "disconnected" throughout the refetch

This defeats the intended behavior at apps/desktop/src/components/settings/ai/shared/index.tsx:180-181 where disabled={localStatus === "checking"} was meant to disable the button during the recheck, and at line 171 where StatusBadge was meant to show a spinner. Neither fires because status never becomes "checking" on refetch.

Impact: The "Connect" button remains clickable with no loading indicator while the recheck is in progress, giving the user no feedback that anything is happening. Users may click it repeatedly.

Suggested change

	const status: LocalProviderStatus = query.isLoading
	? "checking"
	: query.data
	? "connected"
	: "disconnected";
	const status: LocalProviderStatus = query.isLoading || (query.isFetching && !query.data)
	? "checking"
	: query.data
	? "connected"
	: "disconnected";

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[graphite-app]

Origin header construction creates invalid URL

The code constructs an origin from baseUrl, then sends it to an endpoint derived from the same baseUrl. This creates a mismatch:

• Origin: http://127.0.0.1:11434 (extracted from baseUrl)
• Request URL: http://127.0.0.1:11434/v1/models

The Origin header should match the origin of the page making the request, not the target server. In Tauri apps, this should typically be the app's origin (e.g., tauri://localhost).

// Remove this line - Tauri fetch handles Origin automatically
// headers: { Origin: origin },

// Or use a fixed Tauri origin if CORS checking is needed:
const res = await tauriFetch(`${baseUrl}/models`, {
  signal: controller.signal,
  // Origin header typically not needed in Tauri context
});

This could cause CORS preflight failures or unexpected behavior depending on how LM Studio/Ollama validate the Origin header.

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.