Cursor Cloud Agents Setup: 12 Steps, 60 Min [2026]

Cursor quietly renamed one of its most-used features this fall. Background Agents are now called Cloud Agents, and the rename came bundled with self-hosted execution, a new coordinator layer called Projects, and an iOS app that can message a running agent from a phone. Two weeks later, Microsoft shipped VS Code 1.140 with its own answer: experimental multi-folder agent sessions and remote delegation to a connected agent host. If you write code for a living and haven’t touched either feature yet, this is the tutorial that gets you from a blank account to a working multi-repository agent setup in both editors, in under an hour. Both tools sit at the center of the broader shift toward AI-assisted developer software.

The sections below cover through connecting source control, building a development environment, launching a cursor cloud agent against a real repository, and then doing the equivalent setup in VS Code 1.140’s remote delegation workflow. By the end you’ll have a running agent in each tool, a two-repository test project, and a clear answer to which execution model fits your team. According to Stack Overflow’s 2025 Developer Survey, 31% of developers already use AI agents at work and 69% of that group reported a productivity increase, which is the main reason cloud and remote agent execution has become the feature every editor is racing to ship.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

What Changed: Why Cursor Renamed Background Agents to Cloud Agents

Cursor’s own documentation confirms the change in plain language: Cloud Agents were formerly called Background Agents. The underlying mechanics didn’t change much at first glance. A cloud agent still runs in an isolated virtual machine with a full development environment: cloned repositories, installed dependencies, secrets, startup commands, and network access. What changed is scope. Where Background Agents were pitched as a way to keep working while you stepped away from your laptop, Cloud Agents are now positioned as the default way to run AI coding work that needs to build, test, and verify itself against a real environment, in parallel, without tying up your machine.

The practical difference shows up in three places. First, a cloud agent can now run in multi-repo environments, inspecting a full workspace that spans frontend, backend, infrastructure, and shared-library repositories, then opening pull requests in each repo it touches. Second, Cursor added self-hosted machines, so a company that doesn’t want tool execution leaving its network can run the same worker pool on infrastructure it controls, with dynamic scaling and hibernation when idle. Third, Cursor shipped a coordinator layer called Projects in beta on September 10, 2026, which keeps a persistent thread alive and delegates implementation work to parallel subagents instead of making you start a new chat for every task.

None of this requires Projects to get value from a cursor cloud agent. Projects is an optional coordinator on top of the same cloud agent infrastructure this tutorial sets up. Start with a single cloud agent, get comfortable with environments and secrets, and add Projects later if you need a dispatcher that watches Slack channels, schedules, and pull requests for you. Teams that already pair Cursor with Anthropic’s CLI tool have a related option worth knowing about: a walkthrough on building one workflow out of Cursor and Claude Code covers a similar coordinator pattern using a different toolchain.

Prerequisites: Versions, Accounts, and Access You Need

Before you touch a terminal, get these in place. The setup assumes a macOS, Windows, or Linux machine and a repository you’re allowed to let an AI agent push branches to, ideally a disposable test repo for your first run.

Requirement	Minimum version or setting	Where to check
Cursor desktop app	Latest stable build with Cloud Agents docs section	Cursor menu, About Cursor
Cursor plan	Paid plan (cloud agents require a paid tier)	cursor.com/dashboard/billing
Source control provider	GitHub Cloud or Enterprise Server, GitLab, Bitbucket Cloud, or Azure DevOps	cursor.com/dashboard, Integrations
Repository access	Read-write on the repo and any submodules	Your provider’s repo settings
VS Code	1.140 Stable or newer	Help, About, or code –version
VS Code account	Signed in with Copilot or connected agent harness	Accounts icon, bottom left
Remote agent host (optional)	Coder, Daytona, Modal, E2B, or a self-managed host reachable from VS Code	Host provider dashboard
Node.js (for the sample project)	20.x or newer LTS	node –version

You don’t need an Enterprise Cursor plan to follow this tutorial. Cloud Agents are billed at API pricing for whichever model you select, and you’ll be asked to set a spend limit the first time you start using them, which is worth doing before you forget and a long-running agent eats more tokens than you planned.

Step 1: Connect Your Source Control Provider

Open Cursor and go to the dashboard’s Integrations page. Before anyone on an account can start one of these cloud-based agent runs, a Cursor account admin has to connect source control at the account level. Choose GitHub, GitLab, Bitbucket Cloud, or Azure DevOps, then authorize the connection and grant it access to the specific repositories you want agents to work in. If you’d rather not connect a real repository on your first run, Cursor supports starting a cloud agent from scratch with no repository attached, which is a reasonable way to test the workflow before pointing it at production code.

If you’re testing this with a team, note that cloud agent visibility is scoped to the Cursor team the agent was started under, and Cursor separately verifies each viewer’s own repository access before letting them open someone else’s agent run. Connecting your own source control account is a prerequisite for viewing teammates’ agents, not just for starting your own.

Step 2: Turn On Cloud Agents and Set a Spend Limit

With source control connected, open cursor.com/dashboard/cloud-agents. This is where you’ll manage secrets, review Builds, and set the spend limit mentioned above. Set a conservative number for your first week, something like 20 dollars, so a misconfigured agent loop can’t run away with your budget while you’re still learning the environment setup options.

You can start a cloud agent from several places once this is configured: the Cursor desktop app’s dropdown under the agent input (select Cloud), the Cursor iOS app, cursor.com/agents on any device, a Slack @cursor mention, a GitHub or Bitbucket PR comment that mentions @cursor, a Linear @cursor mention, or directly through the API. For this tutorial, use the desktop app so you can watch the environment build in real time.

Step 3: Build a Development Environment with Agent-Led Setup

Environment setup is the single step that determines whether a cloud agent is useful or just expensive. An agent that can write code but can’t run your test suite, query a local service, or reach an internal API can’t close the loop on its own work, which defeats the point of running it unattended. Cursor gives you three ways to configure an environment:

• Agent-led setup: let the agent inspect your repo and propose install steps, then approve or edit them
• Saved snapshot: capture a known-good VM state (installed packages, system dependencies) and reuse it for every run
• Dockerfile: define the environment explicitly in a .cursor/environment.json file checked into your repo

For a first run, agent-led setup is the fastest path. Point the agent at your repository, let it detect your package manager and test runner, and review the commands it proposes before confirming. For anything you’ll run more than a handful of times, switch to the Dockerfile approach so the environment is versioned alongside your code instead of living only in Cursor’s UI. Here’s a minimal example for a Node project with a Postgres dependency:

{
  "build": {
    "dockerfile": ".cursor/Dockerfile"
  },
  "start": "npm run dev",
  "terminals": [
    { "name": "test-watch", "command": "npm run test -- --watch" }
  ],
  "services": {
    "postgres": {
      "image": "postgres:16",
      "env": { "POSTGRES_PASSWORD": "localdev" }
    }
  }
}

Builds prepare each environment in the background so agents start with repositories cloned and dependencies installed rather than paying that cost on every run. The Cloud Agents dashboard shows which environment and Build an agent used, and you can hover over the repository name at the top of an agent’s page to inspect exactly what it ran against.

Step 4: Launch Your First Cursor Cloud Agent

With an environment configured, open the agent input in Cursor, select Cloud from the dropdown, pick your repository and branch, and describe the task in plain language. Something scoped and verifiable works best for a first run, for example: “Add a rate limiter middleware to the Express app in src/server.ts, write a test for it, and open a PR.” Submit the task and watch the Cloud Agents dashboard. You’ll see the environment build, the agent clone the repo, and then a running log of its actions.

A typical first run produces output like this in the agent transcript panel:

[env] Build cached, environment ready in 8s
[agent] Cloning repository: your-org/sample-api (branch: main)
[agent] Installing dependencies via npm ci
[agent] Reading src/server.ts, src/middleware/
[agent] Writing src/middleware/rateLimiter.ts
[agent] Writing test/rateLimiter.test.ts
[agent] Running: npm test -- rateLimiter
  PASS  test/rateLimiter.test.ts
  4 passed, 0 failed
[agent] Opening pull request: feat/rate-limiter-middleware
[agent] Run complete. 1 PR opened. Tokens used: 42,118

Because the agent runs in its own VM, it can build, test, and interact with the changed software without any of that activity touching your laptop, and you can keep working in a local window while it runs. If you’re more used to reviewing changes through Cursor Composer’s diff and rewrite modes, the same review habits carry over to reading a cloud agent’s PR, the agent just produced the diff somewhere else. Cloud agents also support MCP servers, so if your team already has MCP integrations for internal APIs or databases, add them through the MCP dropdown on cursor.com/agents and the cloud agent inherits that access on its next run.

Step 5: Add Secrets and Lock Down Network Access

Most real tasks need credentials: an API key for a third-party service, a database connection string, or a token for an internal tool. Add these under the Secrets tab in Cursor settings rather than committing them to a snapshot or a .env.local file that gets baked into the environment image. Secrets are scoped to your workspace or team, and they’re injected only when a new agent starts, which matters because an agent already running won’t pick up a secret you add mid-run. You have to start a fresh agent after adding or rotating one.

For network access, Cursor manages VM provisioning and isolation for you, but you control the perimeter: restrict outbound domains so the agent can only reach the services it actually needs, and connect to private networks with Tailscale or a similar client if the agent needs to reach something behind a VPN. If your organization requires tool execution to stay inside its own network entirely, this is also the point to evaluate Cursor’s self-hosted machines instead of the default managed cloud workers, which is covered in Step 12.

Step 6: Run Parallel Agents Across a Multi-Repo Workspace

This is where running agents in the cloud earns its keep over a local session. Because each run gets its own VM, you can kick off several agents at once against the same or different repositories without them fighting over your machine’s CPU, memory, or an already-open editor window. For a task that spans a frontend and backend repo, like changing an API contract and updating the client that consumes it, start two agents: one against the backend repo to change the endpoint and update its tests, and one against the frontend repo to update the client call and its types, each referencing the same ticket description so they stay aligned on intent.

Cloud agents can also run in a true multi-repo environment, where a single agent inspects the full workspace across repos and opens coordinated pull requests in each one it changes. Use this mode when the change genuinely can’t be split cleanly, for example a shared-library version bump that needs matching updates in two downstream consumers. Reserve the two-separate-agents pattern for changes that are logically independent even if they’re related, since it’s easier to review two focused PRs than one PR that spans unrelated repositories.

Step 7: Review Artifacts and Take Remote Desktop Control

When a cloud agent finishes, it produces artifacts rather than just a diff: screenshots, short recordings, and logs showing what it changed and how it verified the change. Open the agent’s run page to review these before you look at the code, since they usually tell you in ten seconds whether the agent actually exercised the feature it built or just wrote code that compiles.

For UI changes specifically, Cursor lets you take remote desktop control of the agent’s VM, so you can click through the running application yourself in the exact environment the agent used, without checking the branch out locally. Release control back to the agent when you’re done and it keeps working from where you left it. This is the fastest way to sanity check a frontend change an agent made before you approve the PR.

Step 8: Share an Agent Run and Review with Hooks

Send a teammate the agent’s URL and they can open the run to see the conversation, the code changes, and the artifacts, as long as they’re on the same Cursor team and have their own source control account connected with access to the repository. Team membership by itself doesn’t grant access to a specific agent run, repository access does. A team admin can enable team follow-ups so teammates can send the agent new instructions instead of only viewing read-only history.

If your team has formatting or policy checks that must run on every change, add a .cursor/hooks.json file to the repository so cloud agents run the same command-based hooks locally configured agents use:

{
  "hooks": {
    "afterFileEdit": "npx prettier --write \"$FILE\"",
    "beforeSubmitPrompt": "echo 'Task started' >> .cursor/agent-log.txt",
    "stop": "npm run lint"
  }
}

On Enterprise plans, team-level and enterprise-managed hooks also run automatically, which keeps audit scripts active even when an engineer forgets to configure anything locally. One caveat worth knowing before you debug a hook that “isn’t firing”: hooks don’t run during an agent’s early exploratory turns in a read-only environment, only once it has a writable environment, and user-level hooks from your local ~/.cursor/hooks.json never apply to cloud runs because the VM has no access to your home directory.

Step 9: Update to VS Code 1.140 and Turn On Remote Delegation

VS Code 1.140 shipped as Stable on September 30, 2026, and it’s the first stable release with its own remote agent delegation workflow, aimed squarely at the same problem Cursor Cloud Agents solve: running agent work somewhere other than your laptop. Update first. Open the Command Palette and run Check for Updates, or download the installer directly if you’re more than one or two versions behind.

The release groups its new agent features as experimental or research preview, so you’ll need to enable them explicitly in settings before they appear in the UI:

{
  "chat.agent.multiFolderSessions.enabled": true,
  "chat.agent.remoteDelegation.enabled": true,
  "chat.agent.sharedWorktreeFolders.enabled": true
}

According to VS Code’s own 1.140 release notes, this release also adds a Copilot harness for consistent agent behavior across Copilot products, plus a research-preview feature called HydraFusion that lets multiple models draft, critique, and revise coding tasks without you coordinating them turn by turn. None of these require Cursor at all. If your organization is standardized on GitHub Copilot inside VS Code rather than Cursor, or you’re still weighing VS Code against newer editors like Zed and JetBrains Air, this is the native path to the same multi-repo, remote-execution workflow, and GitHub’s own September 2026 Copilot changelog for VS Code documents the Copilot-side changes that shipped alongside it.

Step 10: Set Up a Multi-Folder Agent Session

With the settings above enabled, open a VS Code workspace that includes more than one folder, for example your frontend and backend repos checked out as siblings. Use File, Add Folder to Workspace to add the second repo if it isn’t already there, then save it as a workspace file so the pairing persists. Open the Chat view, start a new agent session, and you should see an option to scope the session across both folders instead of just the active one.

This mirrors what Cursor’s cloud agents do in true multi-repo mode, but it runs on your own machine inside your normal editor window rather than in an isolated cloud VM. That’s a meaningful tradeoff: you get to watch every edit land in real time and you don’t pay API-plus-compute cloud pricing, but the agent is now competing with you for local CPU and it can’t run unattended once you close the laptop lid.

Step 11: Connect a Remote Agent Host

Remote delegation is the VS Code 1.140 feature that closes the gap from Step 10: instead of running the multi-folder session locally, you delegate the task to a connected remote agent host, which is conceptually the same pattern as Cursor’s self-hosted or cloud workers. Open the Command Palette and search for “Connect Remote Agent Host.” VS Code 1.140 supports connecting to infrastructure such as Coder, Daytona, Modal, E2B, or a self-managed host you expose over SSH with the right agent runtime installed.

Once connected, start a new agent task and choose the remote host instead of your local machine as the execution target. VS Code streams the agent’s output back to your Chat view the same way it would for a local session, but the actual file edits, builds, and test runs happen on the remote host. This is still marked experimental in 1.140, so expect rough edges around reconnecting after a dropped connection, and treat it as a preview rather than something to put in front of a whole engineering org on day one.

Step 12: Decide Between Cloud, Self-Hosted, and Local Worktree Execution

By this point you have three working execution models to choose from, and the right one depends on what you’re optimizing for: speed of iteration, cost predictability, or network isolation. Cursor’s own guidance on choosing where cloud agents run boils down to a simple rule: use managed cloud workers by default, and only reach for self-hosted machines when policy requires tool execution to stay inside your network. Cursor’s self-hosted infrastructure supports dynamic worker pools that scale up under load and hibernate when idle, which keeps the always-on cost down compared to running dedicated VMs around the clock.

For quick, low-stakes edits where you want to watch every keystroke, a local worktree is still faster than spinning up any remote environment. Create an isolated worktree so a background task doesn’t collide with the branch you’re actively editing:

git worktree add ../sample-api-agent-task feat/rate-limiter-middleware
cd ../sample-api-agent-task
code .

VS Code 1.140’s shared worktree folders setting is aimed at exactly this pattern, letting multiple local agent sessions reuse dependency installs across worktrees instead of reinstalling node_modules or a virtualenv for every parallel task.

Execution model	Best for	Cost pattern	Network isolation
Cursor Cloud Agent (managed)	Parallel, unattended, multi-repo tasks	API pricing per model, spend-limit controlled	Cursor-managed VM, outbound domains restricted by you
Cursor self-hosted machines	Compliance-restricted orgs needing in-network execution	Your own compute, scales and hibernates automatically	Fully inside your network
VS Code remote delegation	Teams standardized on Copilot/VS Code wanting off-laptop runs	Depends on connected host provider	Depends on host (Coder, Daytona, self-managed, etc.)
Local worktree session	Fast, low-stakes edits you want to watch live	No extra infra cost, uses local machine	Runs on your machine only

Common Pitfalls When Setting Up Cloud and Remote Agents

Most first-week problems with a cloud-based agent run or a VS Code remote session trace back to one of these five mistakes.

• Skipping environment setup entirely. An agent-led setup you never reviewed will often miss a system dependency your test suite needs, so the first few runs fail on npm test before the agent even gets to your actual task.
• Committing secrets instead of using the Secrets tab. Baking an API key into a saved snapshot or a .env.local file means it’s now part of your environment image indefinitely, and rotating it means rebuilding the snapshot, not just updating one field in settings.
• Not setting a spend limit before the first real run. A vague, open-ended task description can send an agent into a long investigation loop that burns tokens with no PR to show for it, and you won’t notice until the bill does.
• Expecting hooks to run during exploration. If you’re debugging why a preToolUse hook isn’t firing, remember hooks only start once the agent has a writable environment, not during early read-only exploration turns.
• Running remote delegation in VS Code 1.140 on a production branch. This feature is explicitly experimental. Use a disposable branch and a non-critical repo until you’ve seen how your connected host handles a dropped connection mid-task.

Troubleshooting Cursor Cloud Agents and VS Code Remote Sessions

These are the issues most likely to come up in your first few weeks running either workflow, pulled from the patterns both tools’ own support documentation flags most often.

• Agent runs won’t start at all. Confirm you’re logged in and have connected your GitHub, GitLab, Azure DevOps, or Bitbucket account, that you’re on a paid Cursor plan, and that you have the necessary repository permissions on the connected account.
• Secrets aren’t available to the cloud agent. Check you added them in cursor.com/dashboard/cloud-agents under the correct team or workspace, and remember agents already running won’t pick up a secret added after they started.
• Can’t find the Secrets tab at all. This usually means your account lacks the permissions needed to view it, not that the feature is disabled.
• Unsure whether a saved snapshot copied your .env.local file. Snapshots capture whatever was in the base environment at capture time, including .env.local if it existed then, but the Secrets tab is still the recommended way to manage variables going forward.
• A teammate can’t open your agent run. They need to be on the same Cursor team, have their own source control account connected under Integrations, and have access to the specific repository the agent worked in. Team membership alone isn’t enough.
• Slack integration isn’t triggering agents. Verify your workspace admin actually installed the Cursor Slack app and that your own account has the right permissions inside that Slack workspace.
• VS Code’s remote delegation option is missing from the Chat view. Confirm chat.agent.remoteDelegation.enabled is set to true and that you’ve successfully connected a remote agent host first; the option only appears once a host is reachable.
• A remote-delegated task in VS Code drops mid-run after a network blip. Treat this as expected for now since the feature ships as experimental in 1.140; keep tasks short enough to rerun rather than depending on long unattended remote sessions until the feature matures past preview.

Advanced Tips: Hooks, MCP Servers, and Rollouts Monitoring

Once the basic setup is solid, a few features turn a cloud agent from a novelty into something you can trust with real backlog work. First, connect MCP servers your team already uses for internal APIs or databases through the MCP dropdown on cursor.com/agents. Both HTTP and stdio transports are supported, and OAuth works for servers that need it, so an agent can query a real internal system instead of guessing at its shape from code alone. Cloud Agents also ship a built-in Cursor Cloud MCP specifically for run diagnostics, giving you transcripts, run events, and setup logs without leaving the chat.

Second, once you’re comfortable with ad hoc runs, look at Rollouts and Security Review, which Cursor added on September 23, 2026. Rollouts monitors a pull request after it deploys and reports whether each environment looks healthy, regressed, or inconclusive, which closes the loop an agent usually can’t close on its own: knowing whether the change actually worked once it shipped. Security Review checks pull requests for issues like injection vulnerabilities, authentication bypasses, and leaked secrets before a human reviewer even opens the diff.

Third, if you’re running cloud agents from a phone, Cursor’s iOS app added Remote Control on October 6, 2026, which lets you view and message agents running on your own computer, not just cloud runs. It’s on by default for everyone except Enterprise organizations, where an admin has to turn it on explicitly under organizational security settings, so check that setting first if you’re on a managed team account and the option isn’t showing up.

Optional: Add Cursor Projects as a Coordinator Layer

Everything up to this point works with a single cloud agent handling one task at a time. Cursor Projects, which launched in beta on September 10, 2026, sits on top of that same infrastructure and adds a coordinator agent that plans work and hands pieces of it to parallel subagents, without you starting a fresh chat for every new task. If Step 6’s manual pattern of launching two separate agents for a frontend and backend change starts to feel like busywork, this is the feature that automates it.

A Project keeps a persistent thread alive for an initiative rather than a single task, and it uses shared context files that stay in sync between your local machine and whatever cloud environment a subagent runs in, so the coordinator and its subagents are always working from the same understanding of the codebase. You can also wire a Project’s coordinator into Slack channels, recurring schedules, and pull requests through subscriptions, so it picks up new work from wherever your team already tracks it instead of waiting for you to type a prompt.

Under the hood, Cursor’s cloud and self-hosted agents can run on a range of infrastructure providers, including AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel, and E2B, so a Project’s subagents inherit whichever provider your organization has already connected rather than requiring a separate setup. Turn Projects on from the same cursor.com/dashboard/cloud-agents area used in Step 2, point it at the same repositories you connected in Step 1, and start with a narrow initiative, like “keep the health-check endpoint and its client in sync,” before handing it anything broader. A coordinator that’s allowed to subscribe to every Slack channel and every PR on day one will generate more noise than useful work, the same way an overly broad task description burns tokens in a single cloud agent run.

Complete Working Project: A Two-Repo Agent Workflow Walkthrough

Here’s the full setup end to end, assuming a small sample API and a client that consumes it, split across two repositories. This is the project to build the first time you try any of the steps above, before pointing agents at anything that matters.

• Create two throwaway repos: sample-api (a small Express or Fastify service) and sample-client (a minimal frontend that calls one endpoint on it).
• Connect both to Cursor under Integrations, and add both as folders in a single VS Code workspace for the remote delegation comparison later.
• In sample-api, add a .cursor/environment.json like the one in Step 3, committing it so the environment is reproducible for every future agent run.
• Launch a cloud agent run against sample-api with the task: “Add a /health endpoint that returns status and uptime, with a test.” Review the artifacts and merge the PR.
• Launch a second cloud agent against sample-client with the task: “Add a status indicator component that polls the new /health endpoint on sample-api every 10 seconds.” Point it at the merged API change.
• Take remote desktop control of the second agent’s run to click through the status indicator yourself before approving the PR.
• Repeat the same two tasks in VS Code 1.140 using a multi-folder session with both repos open, and again using remote delegation to a connected host, timing each approach.
• Compare the three runs on wall-clock time, whether you had to babysit either local session, and total API spend reported in Cursor’s dashboard.

Running the same small task through all three paths is the fastest way to build real intuition for when running work in the cloud is worth the setup overhead and when a plain local worktree session in VS Code is simply faster for the kind of change your team makes most often.

Cursor Cloud Agents vs VS Code Remote Delegation at a Glance

Neither tool has fully won this feature yet, since VS Code’s version only reached Stable on September 30, 2026, and is still marked experimental internally. The table below summarizes where each one is strongest based on what’s shipped as of this writing.

Capability	Cursor Cloud Agents	VS Code 1.140 Remote Delegation
Maturity	Stable, formerly Background Agents, iterated since 2025	Experimental, shipped in Stable release September 30, 2026
Multi-repo support	Native, agent inspects full workspace and opens PRs per repo	Via multi-folder sessions, also experimental
Self-hosted option	Yes, self-hosted machines with dynamic worker pools	Yes, via connecting a self-managed remote agent host
Mobile control	iOS app with Remote Control, added October 6, 2026	Not natively, depends on third-party extensions
Post-deploy monitoring	Rollouts, added September 23, 2026	Not built in as of 1.140
Model flexibility	Curated model selection with adjustable context window	Multiple models via Copilot harness and HydraFusion preview

If your team is already paying for Cursor, the cloud agent workflow Is the more mature path today, with Rollouts and Security Review closing gaps that VS Code hasn’t filled yet. Teams evaluating whether to drop Cursor entirely in favor of a terminal-first agent can also check a separate step-by-step guide on migrating from Cursor to Claude Code before committing to either setup described here. If you’re standardized on GitHub Copilot and don’t want a second tool subscription, VS Code 1.140’s remote delegation is a credible first step, as long as you treat it as a preview rather than a production dependency for a few more release cycles. Gartner’s research, cited in a 2024 press release, projected that 75% of enterprise software engineers will use AI code assistants by 2028, up from under 10% in early 2023, which is the backdrop explaining why both companies are racing to ship this exact feature in the same month.

Frequently Asked Questions

Is a Cursor Cloud Agent the same thing as a Background Agent?
Yes. Cursor’s documentation states plainly that Cloud Agents were formerly called Background Agents. The rename came with expanded multi-repo support and self-hosted machine options, but any workflow built around the old name still applies.

Do I need a paid Cursor plan to use cloud agents?
Yes, cloud agents require a paid plan, and runs are billed at API pricing for whichever model you select. Set a spend limit the first time you start one.

Can I run a cursor cloud agent without connecting a repository?
Yes. Cursor supports starting a cloud agent from scratch with no repository attached, which is useful for testing the workflow before you point it at real code.

Is VS Code’s remote delegation feature ready for daily use?
Not yet for anything critical. It shipped in the 1.140 Stable release on September 30, 2026, but Microsoft marks multi-folder sessions, remote delegation, and shared worktree folders as experimental, and HydraFusion as a research preview. Treat all three as previews.

What happens to secrets if I add them after an agent is already running?
Nothing, until you start a new run. Secrets are injected when an agent starts, so an agent already in progress won’t pick up a secret you add or rotate mid-run.

Can a teammate see the agent I just ran?
Only if they’re on the same Cursor team, have their own source control account connected under Integrations, and have access to the repository the agent worked in. Being on the same team by itself does not grant access.

Should I use self-hosted machines instead of Cursor’s managed cloud agents?
Only if your organization requires tool execution to stay fully inside your own network for compliance reasons. For most teams, managed cloud agents are simpler to run and scale, and self-hosted machines add operational overhead that only pays off under a specific policy requirement.

Do hooks run while an agent is just exploring my codebase?
No. Hooks like preToolUse and beforeShellExecution only start once the agent has a writable environment, not during the early read-only exploration turns at the start of a run.

Related Coverage

• Best Antivirus Software 2026: Set Up in 13 Steps, 50 Min
• React 19.3 Tutorial: 11 Steps to Ship in 60 Min [2026]
• AWS Fargate: Deploy Containers in 13 Steps, 70 Min [2026]
• Best Pokemon Emulator Setup: 14 Steps, 90 Min [2026]
• Set Up a Portable M.2 SSD: 14 Steps to 3,800MB/s [2026]