Fix primary environment origin on LAN web UI

[huxcrux]

What Changed

Primary-environment requests are still resolving to loopback (127.0.0.1) in LAN-access scenarios. When the WebUI is opened via a LAN host/IP, those loopback-bound calls target the client machine instead of the actual backend host, so key API/bootstrap requests fail. This fix forces request origin resolution to follow the active LAN origin, restoring WebUI reachability over LAN.

Why

To make T3Code work over LAN adress

UI Changes

N/A

Screenshots / How to replicate problem

The problem can be found when enabling network access, generating a new token and trying to use the LAN adress. You will then be shown the following promt:

And when checking network debug in chrome:

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Medium Risk
Changes bootstrap URL selection for all clients; wrong hostname/protocol edge cases could misroute API/WS, but scope is limited to loopback-vs-network origin logic with new tests.

Overview
Fixes primary environment API/WebSocket base URLs when the Web UI is opened on a LAN host while build-time config still points at loopback (127.0.0.1).

readPrimaryEnvironmentTarget in target.ts no longer always uses a configured loopback target. If the page is loaded over http/https on a non-loopback hostname and the configured HTTP base is loopback, resolution switches to the browser window origin (same for the no-config path before desktop-managed fallback). Desktop and existing Vite dev-server proxy behavior stay gated on loopback/window checks.

Tests add env stubs in bootstrap.test.ts, a LAN-vs-VITE_HTTP_URL case, stronger assertions for desktop-managed targets, and a t3code-dev:// window origin for the missing-endpoint test.

^{Reviewed by Cursor Bugbot for commit d4b0be3. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix primary environment origin to prefer network host over loopback config in LAN web UI

• Adds shouldPreferWindowOriginOverConfiguredTarget in target.ts to detect when the page is served from a non-loopback HTTP/HTTPS host while the configured target points to a loopback address.
• Rewrites readPrimaryEnvironmentTarget precedence: non-loopback window origins now override a configured loopback target, fixing LAN access where the browser's actual host was ignored in favor of a localhost config.
• Behavioral Change: readPrimaryEnvironmentTarget may now return the window-origin target instead of a configured loopback target when accessed from a non-loopback host.

^{Macroscope summarized d4b0be3.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 0b79c04c-562c-49ad-9b9f-758e8192db9e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies the primary environment target resolution logic that determines HTTP/WS connection routing. While it's a focused fix for LAN access scenarios, the change to networking behavior and the author's limited history with this file warrants human verification.

^{You can customize Macroscope's approvability policy. Learn more.}