Run Cursor Cloud Agents on Tensorlake Sandboxes

Cursor Cloud Agents can run on self-hosted machines. cursor-cloud-agents-tensorlake makes Tensorlake sandboxes those machines. Cursor keeps the agent loop and the model in its cloud. Every command, file edit, build, and repository checkout runs in a Tensorlake sandbox that you own.

How it works

A small orchestrator runs in its own Tensorlake sandbox. It claims pending Cursor requests and gives each one a dedicated worker sandbox:

Cursor cloud ── pending requests ──▶ orchestrator sandbox
                                       ├─ agent worker controller --spawn cursor-tl-spawn
                                       ├─ janitor: idle worker ➜ suspend, old ➜ terminate
                                       └─ wake: claimed-offline request ➜ resume sandbox
                                                       │
worker sandbox (one per agent) ── agent worker ── outbound HTTPS ──▶ Cursor

Workers only make outbound HTTPS calls to Cursor. No inbound port opens. When a session ends, the worker waits 300 seconds and exits, and the janitor suspends the sandbox. A follow-up message resumes it with the checkout and caches intact. The janitor terminates a sandbox that stays suspended for more than one day.

Setup

You need a Cursor Enterprise team (Cursor offers pools only on Enterprise), a Cursor service-account API key, a Tensorlake API key, and Python 3.10 or newer with uv. A Cursor team administrator first enables Self-hosted Machines and GitHub token minting under Dashboard → Cloud Agents → Self-Hosted, and gives the Cursor GitHub App access to each repository.

Then run one command:

git clone https://github.com/tensorlakeai/cursor-cloud-agents-tensorlake
cd cursor-cloud-agents-tensorlake
uv sync --all-extras
uv run cursor-tl-up

cursor-tl-up asks for both keys once and saves them to .env. It registers the pool, builds the worker and orchestrator images, launches the orchestrator sandbox, and waits until the controller reports watching. The command is idempotent. Run it again after you edit .env, or to repair a suspended orchestrator.

Send a task

Open cursor.com/agents, pick the repository, choose Remote Machines, and pick tensorlake. You can also trigger the pool from Slack (@Cursor pool=tensorlake ...), GitHub (@cursoragent pool=tensorlake ...), Linear, or the API:

uv run cursor-tl-pool agent "Add a unit test for the parser" --repo https://github.com/acme/widgets

A cursor-<worker-id> sandbox appears in tl sbx ls. Each worker starts with the request's repository as its git origin. A checkout hook fetches the requested ref with a short-lived token that Cursor mints for the run, so the worker stores no long-lived git credential.

Computer use

Cursor agents can drive a desktop and a browser on Linux workers. Turn it on for the pool:

uv run cursor-tl-up --computer-use --rebuild

Workers then build from tensorlake/ubuntu-vnc, an Ubuntu desktop with Xfce, Chrome, Firefox, and a VNC server. Ask for something that needs a screen, such as "open example.com and tell me the page title," and the agent opens Chrome, takes screenshots, and acts on what it sees. To watch it live, tunnel the VNC port with tl sbx tunnel cursor-<worker-id> 5901 and open a VNC viewer.

Without an Enterprise team

My Machines works on any Cursor plan and needs no orchestrator. One long-lived worker runs in one sandbox, and you pick it from the environment dropdown at cursor.com/agents:

uv run cursor-tl-my-machine --name tl-demo             # start or resume
uv run cursor-tl-my-machine --name tl-demo --suspend   # memory, filesystem, checkout kept

For the full guide, see the Cursor Cloud Agents docs. For another agent that keeps its loop and runs execution on Tensorlake, see Run Devin Outposts on Tensorlake Sandboxes.