Cursor Cloud Agent Settings: Environments, Secrets, Models

The Environments view lists the saved environments available to your team. Each one can be scoped to a single repo or to a group of repos. Open one to review its setup.

• The repositories it applies to
• Whether it uses a snapshot or .cursor/environment.json
• The install script that runs during Builds
• Runtime secrets and build secrets
• Network access settings
• Version history, Builds, and setup runs

Three actions change an environment. Update with Agent has Cursor inspect the current environment and propose a new setup. New Setup Run has Cursor set up the environment fresh. Restore makes a prior version from version history active again.

The Builds tab shows the prepared environment versions available to Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition.. From there you can inspect logs, trigger a Build, choose or pin the active Build, and start an agent from a specific Build.

Saving an environment's configuration or changing its secrets triggers a new Build. If that Build fails, agents keep starting from the last successful one while you diagnose it. So when a run fails on a credential you know exists, check the Builds tab for a failed Build first. The secrets fix page covers the other causes.

If a new version builds but leaves a working environment worse, restore the last good version or pin an earlier Build first. Then work out what the new version changed.

Set up the environment first, then network access, then everything else in any order. Cursor's cloud agent best practices put environment setup ahead of every other recommendation, and most settings on this page assume an environment that already runs.

Change network access on its own, after the environment works. A blocked domain and a half-built environment can both fail partway through a setup run. If you change both in one sitting, you can't tell which one caused the failure, and an afternoon can go into a Dockerfile that was fine all along.

Prove one clean run before you tighten anything. Agents have internet access by default, so the first run needs no network changes. What you want from it is an install script that finishes and a repo that behaves the way it does on a developer's machine.

Default settings apply when a run doesn't make the choice itself, so they save the most repetitive picks.

The default model is a spend decision as much as a quality one. Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. use plan usage at the selected model's rate. On legacy request-based plans, they always run in Max Mode, priced at API rates plus the Max Mode upcharge. Automations run as cloud agents and always use each model's maximum supported context window, which can raise token use.

A default repository saves a step for a team that works in one repo. On a team with several repos, a pre-filled field is easy to accept without reading, and an agent can then start in the wrong repo. Leave the base branch blank unless your team merges into a branch other than the repository default. If it does, every agent PR forks from the wrong point until you set it.

Network access settings control which network resources Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. can reach. User and team settings support three modes.

Users, team admins and environment owners can all configure network access. An environment can inherit the user or team policy, add its own allowlist on top, or define its own access mode.

Allowlist only is the tightest mode, and it finds your missing domains one failed run at a time. Nothing tells you a host was needed until something tries to reach it. So we'd start below team level: put Allowlist only on one saved environment, run a week of real work through it, and move the policy up once the allowlist stops growing.

If a run that used to work fails after you tighten the policy, first check which hosts your install command reaches. Precedence between the user, environment and team scopes has its own rules, and the security and network page works through them.

All security options require admin privileges. They decide how much of an agent's work is shown, who can steer an agent, and whether Projects need approval to use self-hosted machines.

Turning Display agent summary off removes the quickest check on a run. The file-diff images and code snippets show whether a run went anywhere useful, and without them you have to open something to find out. We'd make that trade on a repo whose file paths are themselves sensitive, not across everything a team owns.

The external-channel toggle extends the first one, so with the summary off it has nothing to extend. Both are admin-only, which means a developer who would rather not publish their diffs can't make that call alone.

Team admins can turn Computer use on or off for their team. It controls whether agents can use computer interaction capabilities, and it is available to enterprise teams only. Changes save instantly and affect new agents immediately. Cursor's settings docs no longer list a separate team feature for long-running agents. For long-running work, they point to /goal in the composer, which needs a recent version of the Cursor app.

Team follow-ups let members send follow-up messages to cloud agents that other users on the same team created. That helps when a teammate starts an agent and someone else needs to course-correct or continue the work while the teammate is away. A teammate must be able to view the agent first, which means belonging to the same Cursor team and having their own access to the agent's repository. Team admins choose one of three options.

It depends on whose credentials the agents carry, and on team size. The lateral-movement risk comes from runs that hold a person's secrets and credentials, and Service accounts only keeps follow-ups away from those runs. A service account is a non-human Enterprise account that starts runs programmatically, for example from a Linear ticket or a Sentry error, and every team admin can see the runs it creates. Follow-ups on its runs reach jobs nobody is watching, while colleagues' agents stay off limits.

Team size decides the rest. On a team of five where everyone holds the same access, All costs very little. On a team of a few hundred, All lets anyone with access to a repository steer agents that carry a more privileged colleague's secrets. That is the escalation Cursor warns about, so leave large teams on Disabled or Service accounts only.