Docker users reported Settings -> Engines failing with 'Failed to load engines:
Failed to fetch'. Two problems: (1) the two API-base resolvers diverged
(client.ts honored VITE_API_URL; apiBase.ts honored VITE_OMNIVOICE_API), and
the docs documented VITE_OMNIVOICE_API -- which the Engines request path
ignored; (2) VITE_* is inlined at BUILD time, so a prebuilt ghcr.io image has
no working runtime override at all for reverse-proxy / split-origin deploys.
- backend: when OMNIVOICE_PUBLIC_API_BASE is set, inject it into index.html as
window.__OMNIVOICE_API_BASE__ (core/spa_inject.py; validated to a plain
http(s) URL so it can't break out of the <script>). Unset (default) ->
StaticFiles serves index.html untouched (same-origin, zero overhead).
- frontend: both resolvers (client.ts _resolveApiBase + utils/apiBase.ts) now
read the runtime global FIRST, then VITE_OMNIVOICE_API/VITE_API_URL, then
fall through to same-origin. client.ts also strips trailing slashes and
recognises __TAURI_INTERNALS__ (parity with apiBase.ts/external.ts).
- docs: docker.md + troubleshooting.md document OMNIVOICE_PUBLIC_API_BASE as the
runtime override that works on the prebuilt image (the old VITE_OMNIVOICE_API
docker run -e example never worked -- build-time inlining).
- tests: spa_inject helpers (inject + URL validation/breakout); resolver
precedence for the runtime global + VITE_OMNIVOICE_API in both test files.
Default same-origin behavior is unchanged on every platform; override is opt-in.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
