When Route traffic rejects private or split-horizon DEV hosts

Route traffic through this computer only relays connections to public internet addresses. When a hostname on your desktop resolves to a private IP (192.168.x.x, 10.x.x.x, or 172.16–31.x.x), the desktop side rejects that connection — CONNECT can return 200, then TLS closes. Staff (deanrie, Sep 23, 2026) on forum 172715.

Public cloud hosts keep working, and the routed this session counter can still increase. A DNS lookup run on the bot computer still goes through the cloud resolver (so you may see a public IP there), while routed traffic is resolved on your desktop.

Staff also noted current docs can imply internal hosts should work this way; they flagged the mismatch internally and did not give an ETA.

Work on the DEV host today

With Execution on this computer allowed for the registered desktop:

1. Open Settings → Computer.
2. Confirm the current computer is selected and Execution on this computer is allowed.
3. Ask the Bot to run DEV checks with Shell or the browser on that desktop, not on the bot’s own cloud computer.
4. Leave Route traffic through this computer for public destinations only until staff ship private-IP relay.

Enterprise private networks (different path)

Team Setup install scripts for Tailscale, Cloudflare Tunnel, and similar clients on team computers follow Connect Grok Bot computers to private networks (official private networks guide). That path is Enterprise Team Setup — it is separate from desktop Route traffic.

Pitfalls

• Do not treat a rising routed this session count as proof the DEV host is reachable — public hosts can succeed while private ones fail.
• Do not invent a toggle that “forces private DNS” on Route traffic; staff described public-only relay as current product behavior.
• Android Waiting for Browser… login loops are a different issue — leave them until staff publish steps.