Grok Bot computers run in Cursor’s cloud and reach the internet through shared static egress IP addresses. If the systems your Bots need, such as internal APIs, source control, databases, or staging environments, live on a private network, you can connect by installing your organization’s networking client on every team computer through Team Setup. Tailscale and Cloudflare Tunnel are common choices, and this page has a worked example for each. Other VPN, zero-trust, or mesh clients that run on Linux follow the same pattern. Your services stay off the public internet, and access is governed by the access controls and identity provider you already use.

Team Setup is Enterprise only. It does not appear on other plans.
Network Controls is also Enterprise only. That
network policy is a separate layer
that still applies; private network reach doesn’t replace your destination
allowlist.

What you can do

  • Install your networking client on every team computer automatically, from one admin-managed manifest, with no per-computer setup.
  • Let Bots reach services on your private network without exposing those services to the internet or adding shared egress IPs to your allowlists.
  • Keep control on your side. Your network, your access rules, your identity provider. You can revoke a computer from your own admin console at any time.

A pattern you operate

This is a pattern you run, not a Cursor-managed network mode. Cursor provides the hook: Team Setup runs your install scripts on every team computer. You own the rest: installing the client, configuring it, authenticating computers, maintaining access rules, and keeping up with your vendor’s changes. Cursor installs nothing by default, doesn’t operate or monitor your network client, and the dashboard shows no client status. Your vendor’s documentation is the source of truth for installing and configuring their software; this page covers the Cursor side.

Before you start

  • You’re a team admin on the Enterprise plan. Team Setup is Enterprise only and doesn’t appear on other plans.
  • Your networking client runs on Debian-based Linux and can be installed and started from a shell script. Team computers run Linux, and scripts run as the computer user with sudo available.
  • Your network has a way in for that client: a gateway, exit node, or tunnel connector inside the VPC or intranet you want to reach, per your vendor’s architecture.
  • You’ve decided how computers will authenticate to your network. Keep credentials out of setup scripts.

How Team Setup runs your scripts

Team Setup lives on the Grok Bot page of the Cursor dashboard: manifests of install scripts that run on every team computer. Each manifest holds one or more script entries, and each entry has an ID, a Setup Script, and an optional Check Script.

  • Scripts run as the computer user on every team computer; use sudo for privileged installs.
  • They run when a computer starts, and on a periodic refresh, roughly daily, while it runs.
  • If a Check Script is present and exits 0, the Setup Script is skipped; use it to avoid reinstalling on every pass. After a setup runs, the check runs again to verify it succeeded.
  • Entries run one at a time, in order. Each script has a 30-minute timeout. A failed script doesn’t block the computer; it’s retried on a later refresh.

Create the manifest

Open Team Setup

Go to Grok Bot in the Cursor dashboard
and open Team Setup.

Create a manifest

Next to Manifests, select + to create a New Manifest, then
enter a Manifest ID, for example private-network.

Write the setup script

In the script entry, set the ID (for example
install-network-client) and write the Setup Script: install your
client following your provider’s Linux install documentation, then start
it and connect it to your network the way your configuration prescribes.

Add a check script

Optionally add a Check Script (for example
command -v <your-client>), so computers that already have the client
skip the install.

Save

Select Save.

Prefer editing JSON? Toggle from Form to JSON at the top of the editor. The manifest structure:

{
  "manifestId": "private-network",
  "entries": [
    {
      "id": "install-network-client",
      "setup": "#!/usr/bin/env bash\nset -euo pipefail\n# 1) Install your networking client per your provider's Linux install docs\n# 2) Start the client and connect it to your network per your configuration",
      "check": "command -v <your-client>"
    }
  ]
}

Do not include secrets. Setup scripts run as the computer user on every
team computer, and manifests are plain text applied to your whole fleet.
Don’t embed auth keys, tokens, or other credentials. Have members
authenticate interactively in the computer’s browser, where your identity
provider’s policies apply, or use a mechanism from your vendor’s
documentation that keeps long-lived credentials out of the script.

Set up your networking client

Whatever tool you use, the last mile is the same: each computer authenticates to your network, you confirm the connection in your vendor’s console, and you verify by asking a Bot to reach an internal hostname it couldn’t reach before. Interactive login happens in the computer’s browser, the same way members already sign in to company tools there. Start with one or two pilot computers before rolling out team-wide.

Tailscale

Run Tailscale on each computer and route through an exit node inside your network. This is the configuration the pattern has been exercised with. Tailscale also offers subnet routers for exposing specific private ranges; validate that arrangement on a pilot computer before relying on it.

Before you start: you operate a tailnet with an exit node inside the VPC or intranet you want to reach.

Team Setup manifest:

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

Connect and verify:

  1. Authenticate each computer. Tailscale prints a login URL that opens in the computer’s browser, where your identity provider’s policies apply. Keep auth keys out of the script.
  2. Confirm the computer appears in your Tailscale admin console and is allowed to use the exit node.
  3. Ask a Bot to reach an internal hostname.

If it doesn’t work:

  • The client installed but nobody authenticated. The login step is deliberately manual, since scripts can’t hold secrets. Check the machine list in your Tailscale admin console.
  • Your team’s network policy is allowlist-only and blocks Tailscale’s coordination servers or relays. Allow the endpoints from Tailscale’s docs, then recreate the computer.
  • The exit node isn’t advertised or approved in your tailnet. Check route settings in the admin console.
  • The computer was recreated, for example after an image update or reset, and the session didn’t survive. Authenticate again.

Cloudflare Tunnel

The same Team Setup mechanics work for Cloudflare Tunnel: a cloudflared connector inside your network publishes private services through Cloudflare’s edge, protected by Cloudflare Access, and the computer reaches them by hostname. This arrangement hasn’t been exercised on team computers the way the Tailscale one has, so validate it on a pilot computer before rolling out.

Before you start: you run a Cloudflare Tunnel connector inside your private network, with the services you need routed through it, and you’ve chosen your Cloudflare Access policy. Identity-based policies fit this pattern well, since members sign in through the browser. Access service tokens are secrets; keep them out of setup scripts.

Team Setup manifest:

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

Connect and verify:

  1. Private HTTP services: reach them at the hostname you routed through the tunnel. Cloudflare Access enforces your policy; with identity-based policies, the member signs in through the computer’s browser.
  2. Private TCP services, such as databases or SSH: run cloudflared access tcp on the computer to open a local listener and point the tool at it. Cloudflare’s docs cover the flow. A Bot can start the listener in its shell when it needs the service.
  3. Ask a Bot to reach the private hostname or service.

If it doesn’t work:

  • The connector inside your network is down. Check tunnel health in your Cloudflare dashboard; this fails on your side, not the computer’s.
  • Cloudflare Access denies the request. Check your Access logs and confirm the member has authenticated.
  • Your team’s network policy is allowlist-only and blocks the tunnel hostname or Cloudflare’s endpoints. Allow them, then recreate the computer.
  • A service token was embedded in the setup script. Don’t do this; manifests are plain text. Use identity-based Access, or supply tokens at use time.
  • A cloudflared access tcp listener isn’t running when the Bot needs it. Listeners don’t persist across sessions; start one when needed.

Choosing between them: Tailscale gives the computer network-level reach, and with an exit node, egress from your network. Cloudflare Tunnel publishes specific services through Cloudflare’s edge behind Access: per-service rather than whole-network, and egress addresses seen by other services don’t change.

Other clients that install and run on Debian-based Linux follow the same Team Setup steps; validate yours on a pilot computer before rolling out.

Roll out to existing computers

  • New computers apply manifests when they’re created.
  • Running computers pick up manifest changes on a periodic refresh; expect up to about a day.
  • To apply immediately, restart or recreate the computer. Members can reset their own computer from the desktop app, and organization admins can terminate a member’s computer from the dashboard. The durable disk is kept, and the next session starts a fresh computer that applies current manifests at boot.
  • Image updates recreate computers automatically, and your scripts re-apply. Sign-in sessions, including your network client’s login, may need to be re-established after a computer is recreated.

Work with the network policy

The Grok Bot network policy is a separate layer that controls which destinations team computers may reach. If your team uses Team allowlist only, add the destinations your networking client needs, such as coordination servers, relays, and gateways, from your vendor’s documentation. Network policy changes apply when a computer is created or recreated.

Limitations

  • This is a pattern you operate, not a Cursor-managed network mode. Cursor doesn’t install, operate, or monitor your networking client, and support for the client itself comes from your vendor.
  • Regular internet traffic still egresses through Cursor’s shared static IP ranges unless you route it through your own network. Dedicated per-customer egress IPs are not available.
  • There’s no fleet view of script results today. Verify a pilot computer before rolling out team-wide.
  • This is not the Cloud Agents setup. The Cloud Agents docs have their own Tailscale and Cloudflare Tunnel recipes for a different product surface; Grok Bot computers are configured through Team Setup as described here. If Grok Bot delegates work to Cloud Agents, those agents run under Cloud Agent network settings, not your computer’s network client.

FAQ

Can I put an auth key or credential in the setup script?

No. Setup scripts are not a secret store, and the dashboard warns against
including secrets. Authenticate computers interactively, or use a
mechanism from your vendor’s docs that doesn’t require embedding a
long-lived credential in the script.

Which networking tools can I use?

Any client your team can install and run on Debian-based Linux from a
shell script. Tailscale and Cloudflare Tunnel are the worked examples on
this page. Validate your client on a pilot computer first.

Do existing computers get a new manifest?

Yes, within about a day. Running computers refresh manifests
periodically. Restart or recreate a computer to apply changes
immediately.

Does this change the IP addresses my services see?

For traffic routed through your network, yes. Traffic to your private
network arrives from inside your network, via your exit node, gateway, or
tunnel connector. Everything else continues to egress from Cursor’s
shared static ranges.

We use a strict network allowlist. Will our client work?

Only if you allow its endpoints. Add the destinations your client
requires to your team allowlist, then recreate computers to pick up the
policy change.

Is this the same as the Tailscale and Cloudflare Tunnel sections in the Cloud Agents docs?

No. Those recipes are specific to Cloud Agent VMs; Tailscale there
requires userspace networking and proxy variables. Grok Bot computers use
Team Setup and your own gateway or connector, as described on this page.

Which plans include Team Setup?

Team Setup is Enterprise only. Team admins manage manifests. If you
don’t see it on the Grok Bot page of the dashboard, you are not on
Enterprise, or you need your account team to enable Grok Bot for the
organization.

What happens if the setup script fails on some computers?

The computer still starts. Failed entries are retried on a later
refresh. Keep scripts re-runnable and use a Check Script so healthy
computers skip the install.