Every user should be able to rent a Cursor computer, and this Cursor computer should serve as permanent installation storage for our background agents. Our Cursor should be able to use CLI tools such as the Cursor CLI and Supabase CLI. In this way, the Cursor background agent can run our project tests in its own virtual environment, deploy, monitor and manage them, detect errors and act as a test environment for quality assurance analyses; this, in turn, speeds up our workflow.
Hey, thanks for the feature request. Good news, most of this already works in Cloud Agents.
A Cloud Agent is basically that Cursor computer. It’s an isolated Linux VM where your repo is cloned and you can run tests, deploy, etc. To make CLI tools like Cursor CLI, Supabase CLI, and others persist between runs, add them to .cursor/environment.json. The install scripts run during environment setup, and the Machine Snapshot caches the installed software so it doesn’t get wiped between runs. That’s the permanent installation storage you’re asking about.
If you specifically need a dedicated, persistent machine you control, check out self-hosted My Machines: My Machines | Cursor Docs
One note: the snapshot keeps installed software and environment config, but it won’t keep live running processes between runs. So it’s not an always-on service that keeps processes running all the time yet. If you need that part specifically, tell me what exactly needs to run continuously and I’ll flag it as a separate request.
Thank you. My favourite teammate is the cursor. Does the cursor also allow me to create flows? For example, having Graph flows that would organise operations based on scenarios running on the Cloud Agent would make my job much easier. It would be brilliant to set up my own Cloud Agent Graph to periodically repeat my QA tests, identify security vulnerabilities and experiment with autonomous deployment.
Hey, you can already put part of this together today.
For periodically repeating QA tests, Cloud Agent Automations should work. They let you run an agent on a schedule or on an event like a GitHub trigger. That covers the recurring and scheduled part: Automations | Cursor Docs
For orchestrating steps into scenarios, there are two options:
Subagents: the main agent can delegate tasks to specialized subagents: Subagents | Cursor Docs
But there isn’t a visual graph flow editor where you can draw a node graph with conditions as a first-class feature yet. If you need something like that with drag-and-drop scenario orchestration, describe what the ideal version looks like. What nodes you want, what transitions you need. Also, please create a feature request for it. Let me know.
This makes sense. Once background agents start running tests, deploys, and Supabase/CLI workflows in their own environment, the next big need is persistent project safety state.
The agent should not just “run commands”; it should know when it has changed auth boundaries, database access, RLS-related migrations, webhook code, or env/key usage in a risky way.
I’ve been building PreFlight around this exact layer: a local daemon that watches the repo for AI-induced security/architecture drift while agents keep working in the background.