Connect Grok Bot computers to private networks

Grok Bot computers run in Cursor’s cloud and reach the public internet through shared static egress IPs. When Bots need internal APIs, source control, databases, or staging hosts that stay off the public internet, install your organization’s networking client on every team computer with Team Setup. Official guide: Connect to private networks.

Enterprise only. Team Setup does not appear on self-serve Teams. The Grok Bot network policy still applies; private-network reach does not replace a destination allowlist.

What Cursor provides vs what you own

Cursor runs your install scripts on every team computer through Team Setup. You own installing the client, configuring it, authenticating computers, access rules, and vendor updates. Cursor does not install a client by default, does not monitor your network client, and the dashboard shows no client status.

Team computers run Debian-based Linux. Scripts run as the computer user with sudo available. Keep credentials out of setup scripts.

Create a Team Setup manifest

1. Open Grok Bot in the Cursor dashboard and open Team Setup.
2. Next to Manifests, choose + → New Manifest. Set a Manifest ID (for example private-network).
3. In the script entry, set an ID (for example install-network-client).
4. Write the Setup Script: install your client per the vendor’s Linux docs, then start it and join your network the way your config requires.
5. Optionally add a Check Script (for example command -v <your-client>) so computers that already have the client skip reinstall. After setup runs, the check runs again to verify success.
6. Save. Prefer Form mode, or toggle to JSON.

JSON shape:

{
  "manifestId": "private-network",
  "entries": [
    {
      "id": "install-network-client",
      "setup": "#!/usr/bin/env bash\nset -euo pipefail\n# install client, start it, connect per your config",
      "check": "command -v <your-client>"
    }
  ]
}

Scripts run at computer start and on a periodic refresh (roughly daily). Entries run one at a time, in order, with a 30-minute timeout each. A failed script does not block the computer; it retries on a later refresh. If a Check Script exits 0, Setup is skipped.

Tailscale (worked example)

Operate a tailnet with an exit node inside the VPC or intranet you want to reach. Subnet routers can expose private ranges; validate on a pilot computer first.

• Setup Script: install Tailscale for Linux per Tailscale’s install docs, then bring the computer onto your tailnet.
• Check Script: command -v tailscale.

Connect and verify:

1. Authenticate each computer. Tailscale prints a login URL that opens in the computer’s browser (IdP policies apply). Keep auth keys out of the script.
2. Confirm the computer appears in your Tailscale admin console and may use the exit node.
3. Ask a Bot to reach an internal hostname it could not reach before.

If it fails: nobody authenticated; allowlist-only Network Controls block Tailscale coordination/relays (allow those endpoints, then recreate the computer); exit node not advertised/approved; or the computer was recreated and needs a fresh login.

Cloudflare Tunnel (worked example)

Run a cloudflared connector inside your private network. Publish services through Cloudflare’s edge behind Access. Validate on a pilot computer before team-wide rollout (this path has been exercised less than Tailscale on team computers).

• Setup Script: install cloudflared per Cloudflare downloads. Only the client goes on the computer; the connector stays in your network.
• Check Script: command -v cloudflared.

Connect and verify:

1. Private HTTP: reach the hostname you routed through the tunnel. With identity-based Access, the member signs in in the computer browser.
2. Private TCP (databases, SSH): run cloudflared access tcp on the computer for a local listener, then point the tool at it. A Bot can start the listener in its shell when needed. Listeners do not persist across sessions.
3. Ask a Bot to reach the private hostname or service.

If it fails: connector down on your side; Access denies the member; allowlist-only policy blocks tunnel/Cloudflare endpoints (allow, then recreate); service token embedded in the script (remove it — use identity-based Access or supply tokens at use time); TCP listener not running when needed.

Choose: Tailscale for network-level reach (and egress via exit node). Cloudflare Tunnel for per-service publish behind Access without changing egress addresses other services see.

Other VPN, zero-trust, or mesh clients that install and run on Debian-based Linux from a shell script follow the same Team Setup pattern. Pilot first.

Roll out to existing computers

• New computers apply manifests at create time.
• Running computers pick up changes on periodic refresh (up to about a day).
• For immediate apply: restart or recreate the computer. Members can reset from the desktop app; organization admins can terminate a member’s computer from the dashboard. Durable disk is kept; the next session starts fresh and applies current manifests at boot.
• Image updates recreate computers automatically and re-apply scripts. Network-client login may need to be re-established after recreate.

Work with Network Controls

If the team uses Team allowlist only, add destinations your networking client needs (coordination servers, relays, gateways) from the vendor’s docs. Network policy changes apply when a computer is created or recreated.

Pitfalls

• Secrets in manifests land on every team computer as plain text — authenticate interactively or use a vendor mechanism that keeps long-lived credentials out of the script.
• Regular internet traffic still egresses through Cursor’s shared static ranges unless you route it through your own network. Dedicated per-customer egress IPs are not available.
• No fleet view of script results today — verify a pilot before wide rollout.
• Cloud Agents Tailscale / Cloudflare recipes are a different product surface. Grok Bot computers use Team Setup as on this page. Delegated Cloud Agents follow Cloud Agent network settings, not your computer’s client.