fix(client): use window.location.hostname for remote/Docker deployments

[abhid]

Problem

When running OmniVoice Studio in Docker and accessing it from a remote machine (e.g. over Tailscale or LAN), the frontend fails entirely — every API call hits ERR_CONNECTION_REFUSED because the client is hardcoded to 127.0.0.1.

This is tracked in #120.

Root Cause

frontend/src/api/client.ts always builds the API base URL as:

`http://127.0.0.1:${_port}`

This works fine in Tauri desktop builds (where the backend sidecar runs locally), but breaks in any browser-based deployment where the server is on a different host.

Fix

Detect the Tauri context via window.__TAURI__ and use 127.0.0.1 only for native desktop builds. For all other cases (Docker, web server), use window.location.hostname so the frontend talks to whatever host it was loaded from.

const _host =
  typeof window !== 'undefined' && window.__TAURI__
    ? '127.0.0.1'
    : (typeof window !== 'undefined' ? window.location.hostname : '127.0.0.1');
export const API = viteEnv.VITE_API_URL || `http://${_host}:${_port}`;

• ✅ Tauri desktop: unchanged behaviour (127.0.0.1)
• ✅ Docker remote access: uses actual server hostname
• ✅ VITE_API_URL env override still takes priority

Fixes #120

Summary by CodeRabbit

• Bug Fixes
  • Fixed API endpoint configuration to properly support remote and hosted deployments, allowing the application to reach the backend from different network locations based on deployment context.

[coderabbitai]

📝 Walkthrough

Walkthrough

The API endpoint construction in the frontend client is updated to dynamically select the backend host based on the deployment context. Tauri builds continue using localhost, while browser-based deployments now use the current window hostname to reach remote backends.

Changes

API Host Selection

Layer / File(s)	Summary
Dynamic host selection for API endpoint frontend/src/api/client.ts	API host selection logic branches on Tauri detection: uses 127.0.0.1 for Tauri builds, window.location.hostname for browser contexts, with a fallback to 127.0.0.1 when window is unavailable.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A rabbit hops through browser lands,
No more stuck at local strands!
With Tauri's firm and steady paw,
And window hosts—no glitching flaw. ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description provides clear problem statement, root cause analysis, and implementation details. However, it lacks the formal template sections (Summary, Changes, Type checkbox, Testing, Checklist) required by the repository guidelines.	Fill out the required description template sections including: Summary, Changes list, Type checkbox selection, Testing methodology, and Checklist items to match repository standards.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: fixing the API client to use window.location.hostname for remote/Docker deployments instead of hardcoded 127.0.0.1.
Linked Issues check	✅ Passed	The PR directly addresses issue #120 by implementing the expected behavior: respecting VITE_API_URL env variable priority while falling back to window.location.hostname for browser deployments, and maintaining 127.0.0.1 for Tauri desktop builds.
Out of Scope Changes check	✅ Passed	The change is focused solely on the API client host detection logic in frontend/src/api/client.ts, directly addressing the linked issue #120 without introducing unrelated modifications.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint skipped: no ESLint configuration detected in root package.json. To enable, add eslint to devDependencies.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/src/api/client.ts`:
- Around line 7-11: The API base resolution in frontend/src/api/client.ts is out
of sync with the contract in frontend/src/utils/apiBase.ts: update the Tauri
detection to check window.__TAURI_INTERNALS__ || window.__TAURI__ (not just
window.__TAURI__), derive the protocol from window.location.protocol when not
running under Tauri (avoid hardcoded "http://"), and use the same environment
override variable name VITE_OMNIVOICE_API instead of viteEnv.VITE_API_URL;
update the logic that builds API (variables _host, _port, API and the viteEnv
usage) so the final API string matches the protocol+host:port format used by
apiBase.ts and allows the env override to take precedence.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ffe1123e-6814-4ed8-8e01-0c026cb0120f

📥 Commits

Reviewing files that changed from the base of the PR and between b34dcd9 and 2ec4129.

📒 Files selected for processing (1)

• frontend/src/api/client.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify current runtime-contract usage consistency (read-only).
rg -n -C3 '__TAURI_INTERNALS__|__TAURI__|getApiBase\(|window\.location\.protocol|window\.location\.hostname' frontend

Repository: debpalash/OmniVoice-Studio

Length of output: 15050

---

Major: align frontend/src/api/client.ts API base resolution with frontend/src/utils/apiBase.ts contract (Tauri + protocol + env override)

• Tauri detection drift: client.ts treats Tauri as window.__TAURI__ only, while apiBase.ts uses window.__TAURI_INTERNALS__ || window.__TAURI__.
• Protocol drift / mixed-content risk: client.ts hardcodes http://..., but apiBase.ts resolves the protocol from window.location.protocol (tests cover https).
• Env override key mismatch: client.ts uses viteEnv.VITE_API_URL, while apiBase.ts overrides via VITE_OMNIVOICE_API (override behavior can diverge between call sites).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/api/client.ts` around lines 7 - 11, The API base resolution in
frontend/src/api/client.ts is out of sync with the contract in
frontend/src/utils/apiBase.ts: update the Tauri detection to check
window.__TAURI_INTERNALS__ || window.__TAURI__ (not just window.__TAURI__),
derive the protocol from window.location.protocol when not running under Tauri
(avoid hardcoded "http://"), and use the same environment override variable name
VITE_OMNIVOICE_API instead of viteEnv.VITE_API_URL; update the logic that builds
API (variables _host, _port, API and the viteEnv usage) so the final API string
matches the protocol+host:port format used by apiBase.ts and allows the env
override to take precedence.

[Et-008]

The _host variable condition can be written a bit cleaner...

const _host = typeof window !== 'undefined' && !window.__TAURI__ ? window.location.hostname : '127.0.0.1';