Web client refuses to connect to a localhost server when the browser reports navigator.onLine === false #29323

What happened

I ran npx t3@latest (v0.1.6) and opened http://localhost:3773 in Chrome. The page loaded and the browser logged in, but the composer showed "Mac mini de Antoine is offline — This device is offline", and pressing Reconnect did nothing. Chrome was reporting navigator.onLine === false because of a browser extension (Claude in Chrome); the network was fine. The same server worked in Safari, in a Chrome guest profile, and from the desktop app.

Diagnosis

apps/web/src/connection/platform.ts:68 (currentNetworkStatus) reads the browser's network status directly from navigator.onLine. When that is "offline", EnvironmentSupervisor (packages/client-runtime/src/connection/supervisor.ts) starts in the offline phase and never calls ConnectionDriver.connect. That includes the primary environment the page was served from, which is on loopback and needs no internet. The trace confirms it: HTTP auth succeeds, EnvironmentSupervisor.make runs for the PrimaryConnectionTarget, and every RPC then fails with EnvironmentRpcUnavailableError, with no connect or websocket span. diagnosis.ts then says "This device is offline" while naming the server host, which sent me looking at the server instead of the browser. The code is the same on main.

Suggestions:

1. Treat navigator.onLine as a hint, not a gate, for the primary or same-origin environment. If the page was just served by this server, try to connect anyway.
2. Make the banner say the browser is reporting no network, rather than marking the server host offline.

Steps to reproduce

1. npx t3@latest and open http://localhost:3773 in Chrome.
2. Make Chrome report offline while the network still works. In our case the Claude in Chrome extension caused this. To reproduce reliably, use CDP Network.emulateNetworkConditions({offline: true}) on the tab, or override navigator.onLine to false before the app starts.
3. Reload. The banner shows " is offline — This device is offline", Reconnect does nothing, and no WebSocket connection is attempted.

Version

Server and web client: 0.1.6 (npx t3@latest). Triage CLI: 0.1.6. The desktop app T3 Code (Beta) 0.1.5 on the same machine was not affected.

Environment

macOS 25.6.0 (arm64), Node v26.12.1. Server via npx t3@latest, accessed through Chrome on localhost:3773. Chrome profile managed by Google Workspace; Claude in Chrome extension 1.0.104 on.

Evidence

server.trace.ndjson, run started 12:59:54 UTC:

12:59:58.565 environment.auth.browserSession POST /api/auth/browser-session -> Success
12:59:58.702 EnvironmentSupervisor.make {target.kind: PrimaryConnectionTarget}
12:59:58.872 EnvironmentRpc.request server.refreshProviders -> EnvironmentRpcUnavailableError: "<host> is not connected."
13:00:03.203 EnvironmentRpc.request server.reportClientActivity -> EnvironmentRpcUnavailableError
(no ConnectionDriver.connect / environment.websocket.connect spans)

For comparison, at 12:58:40 the desktop app connected normally (ConnectionDriver.connect then environment.websocket.open).
`navigator.onLine` in the failing tab's console: `false`.

Related issues

Possibly related: #17106, #17629 (closed).

Fix applied or workaround

Turning off the Claude in Chrome extension made navigator.onLine return true, and the app connected. Safari, a Chrome guest profile, or the desktop app also work.

Filed by

Claude Opus 5.5 (claude-opus-5-5) in Claude Code, via t3 triage.