Problem

Closes #22047

bind: "lan" causes the browser tool (and any Gateway self-connection) to fail with a SECURITY ERROR after the plaintext ws:// block introduced in #20803.

Two commits are in conflict:

• fix(gateway): use LAN IP for WebSocket/probe URLs when bind=lan #11448 — localUrl now uses the LAN IP when bind=lan
• fix(security): block plaintext WebSocket connections to non-loopback addresses #20803 — plaintext ws:// to non-loopback addresses is rejected

Result: agents running on the same host as the Gateway hit SECURITY ERROR: Gateway URL "ws://192.168.x.x" uses plaintext ws:// to a non-loopback address.

Fix

localUrl in buildGatewayConnectionDetails() always uses ws(s)://127.0.0.1:<port> regardless of bind mode.

bind controls which interface the server listens on — it should not affect the connection URL for agents on the same host. LAN/tailnet IPs are still available in lanIPv4 / tailnetIPv4 for display purposes (QR codes, urlSource labels, onboarding hints).

Changes

• src/gateway/call.ts: localUrl simplified to ws(s)://127.0.0.1:${localPort}
• src/gateway/call.test.ts: updated test names and assertions to reflect new behavior

Tests

✓ src/gateway/call.test.ts (29 tests) 167ms

All 29 tests passing.

Greptile Summary

Fixes a regression where bind: "lan" caused browser tools and Gateway self-connections to fail with SECURITY ERROR due to a conflict between two previous commits. The fix ensures agents on the same host always connect via 127.0.0.1 regardless of bind mode, since bind controls which interface the server listens on, not the connection URL for local agents. LAN/tailnet IPs remain available for display purposes (QR codes, onboarding hints).

• Modified buildGatewayConnectionDetails() in src/gateway/call.ts to always use ws(s)://127.0.0.1 for localUrl, removing the conditional logic that previously used LAN/tailnet IPs based on bind mode
• Updated all related tests in src/gateway/call.test.ts to reflect the new behavior, converting tests that expected SECURITY ERROR exceptions into tests that verify loopback connections succeed
• All 29 tests passing, confirming the fix resolves the security error while maintaining proper functionality

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix correctly resolves a clear regression caused by conflicting commits. The change is well-contained, maintains backward compatibility for all use cases, and actually improves security by ensuring local agents always use loopback addresses. All 29 tests pass, including updated tests that specifically verify the new behavior works correctly for all bind modes (loopback, lan, tailnet) with and without TLS. The implementation is simple, well-commented, and aligns with the security principle that ws:// to non-loopback addresses should be blocked.
• No files require special attention

_{Last reviewed commit: e97ebcf}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}