Manage and protect

Connect to private networks

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 available on the Enterprise plan. The Grok Bot network policy is a separate layer that still applies; private network reach does not 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, and 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, does not 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 are a team admin on the Enterprise plan. Team Setup does not 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 have 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 does not block the computer; it is retried on a later refresh.

Create the manifest

  1. Go to Grok Bot in the Cursor dashboard and open Team Setup.
  2. Next to Manifests, select + to create a New Manifest, then enter a Manifest ID, for example private-network.
  3. 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.
  4. Optionally add a Check Script (for example command -v <your-client>), so computers that already have the client skip the install.
  5. Select Save.

If you prefer editing JSON, toggle from Form to JSON at the top of the editor. The manifest has this structure:

JSON

{
  "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. Do not 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 could not 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 does not work:

  • The client installed but nobody authenticated. The login step is deliberately manual, since scripts cannot 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 is not 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 did not 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 has not 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 have 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 does not 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. Do not do this; manifests are plain text. Use identity-based Access, or supply tokens at use time.
  • A cloudflared access tcp listener is not running when the Bot needs it. Listeners do not persist across sessions; start one when needed.

To choose 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 the egress addresses that other services see do not 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 are created.
  • Running computers pick up manifest changes on a periodic refresh; expect up to about a day.
  • To apply a change 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 does not 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 is 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 does not 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?

Enterprise. Team admins manage manifests. If you do not see Team Setup on the Grok Bot page of the dashboard, contact your account team.

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.


Last updated: September 2, 2026