ince about 3 PM ET on Nov 6, 2026, the browser on my Grok Bot computer can’t reach anything running locally on that computer. Before that, my bot ran small port forwarders on 127.0.0.1 (ports 7080 and 7081) that relay over Tailscale (installed on the bot computer) to my home NAS. The browser opened those local ports fine, and I’d been using that setup for weeks.
Now:
The box has a new nftables table, inet sand_browser. It rejects every TCP SYN from the interactive/browser cgroup to lo, except port 8791 (the egress proxy).
Chrome is launched with --proxy-server=http://127.0.0.1:8791, and the egress proxy returns 403 for 127.0.0.1 and for private/Tailscale addresses (100.x and 10.x).
In the browser, 127.0.0.1:7080 shows ERR_CONNECTION_REFUSED.
The shell still reaches the same services fine: curl to the NAS’s Tailscale IP returns HTTP 200.
Public websites load normally in the browse
Steps to Reproduce
Update Bot’s Computer (completed, no change), turning “Route traffic through this computer” off and on (no change; the settings row shows “1 site blocked: it resolves to a private or VPN address that your organization hasn’t allowed for local egress”), and restarting Tailscale and the forwarders. I have not run Reset.
Expected Behavior
The browser should be able to open services listening on the bot computer’s own loopback, as it did before Nov 6. Or, if this is an intentional change, there should be a supported way for non-Enterprise users to allow the browser to reach a self-hosted private service (my NAS over Tailscale).
Operating System
MacOS
iOS
Version Information
Grok Bot on macOS and iOS, bot computer updated Nov 6, 2026
Additional Information
Is the loopback block intentional? If it is, what’s the supported way to let the bot’s browser use a local web app reached over Tailscale on a personal (non-Enterprise) plan?
Does this stop you from using Cursor
Yes, browser-based uploads to my self-hosted apps are blocked.
I’m not on the team, but this is how it looks to me.
About private and Tailscale addresses: based on the docs, this seems to be expected behavior. When Route traffic through this computer is enabled, sites that resolve to private or VPN addresses are blocked unless the org has allowed them. That’s also why you see “1 site blocked” in settings. For access to private networks, the docs suggest installing the networking client through Team Setup Scripts, but that option, along with Network Controls and Allow Local Egress Routing, is only available on Enterprise: Connect to private networks | Cursor Docs
I couldn’t find anything in the docs about loopback, meaning 127.0.0.1 on the bot’s own machine. So whether that’s intended or not can only be confirmed by the team, and for now we’re waiting for their reply.
Since shell can reach the NAS, a temporary workaround is to have the bot do downloads through shell using curl or the NAS app’s own CLI instead of the browser. It’s not as convenient, but it should work.
To make it easier for the team to look into this, it would help to add the Grok Bot app version from Support > About and, if possible, the request ID or bot ID from the session where the browser hits ERR_CONNECTION_REFUSED.
Hi @RM_PANDA2297, yes, the loopback block is intentional. It’s a security change that bot computers pick up when they’re rebuilt on the current image, which is why it started for you on Nov 6. Without it, any web page open in the bot’s browser could connect to services running on the bot’s own machine. The browser can now only use its built-in proxy on loopback. The shell isn’t affected, which is why curl to your NAS still works.
We’re also blocked from visually testing a game on a bot-local server. Shell requests succeed, but the bot’s browser reports `ERR_CONNECTION_REFUSED` for `127.0.0.1:8765`, even for a static version file. Older game builds have shown the same issue.
Is there a supported way to preview a bot-local development server under the current browser restrictions? If not, is an earlier computer image available without losing files or browser logins? We’re looking for a supported solution, not a way around security controls.
Thanks for your response. Looks like Colin confirmed it was an intentional block. I’m working on an alternate way of Grokbot accessing the page (but not the rest of my network,) that has been successful and I’m doing more testing.
In regards to curl, the thing is the bot is literally taking a bunch of PDFs and uploading to my web app.
I need a supported way to preview a development site privately on my Grok Bot computer before publishing.
On November 8, 2026, the browser returned net::ERR_CONNECTION_REFUSED for http://127.0.0.1:8768/#creed at 6:05:54 PM and 6:06:00 PM EST. At 6:05:58 PM EST, a command-line request to the same server returned HTTP 200. The server was listening on that address, a video byte-range request returned HTTP 206, and all 11 computer diagnostics passed.
Command-based tests pass, but this blocks actual video playback and audio-handoff checks. The pending changes have not been published.
Your reply in this thread describes an intentional browser loopback restriction. Does that rollout apply to my computer, and what is the approved private development-preview workflow? I want to test before publishing without bypassing security or exposing the preview publicly.
Thanks for the feedback on this. I don’t have a workaround to share right now, but I’ve shared the gap (viewing local dev servers in browser) with the team.
My Grok Bot runs a Python Dash dashboard on its own computer (port 8058). From the shell it returns HTTP 200, but the bot’s browser refuses localhost and 127.0.0.1, and the box’s network addresses return a 403 from the browser proxy. It looks like a deliberate loopback block on the browser.
My workaround is to export the dashboard as a self-contained HTML file with plotly.js inlined and the scenario math ported to JavaScript, then open it from a local file path. That works well and recomputes live, but it can’t pull in new data without a rebuild.
Has anyone found a supported way to view a live local server in the bot’s browser, such as an allowlist setting or a preview feature? Or do you have a better pattern for showing live local dashboards?