Cursor Cloud Agent Settings: Environments, Secrets, Models

The Environments view lists the saved environments available to your team, and each one can be scoped to a single repo or to a group of repos. Opening an environment shows everything that defines how an agent starts. The list below covers what you can review inside one.

• The repositories it applies to
• Whether it uses a snapshot or .cursor/environment.json
• The update script that runs before an agent starts
• Runtime secrets and build secrets
• Network access settings
• Version history and setup runs

Three actions drive changes to an environment. Use Update with Agent to have Cursor inspect the current environment and propose a new setup, New Setup Run to have Cursor start setting up the environment fresh, and Restore from version history to make a prior environment version active again.

An environment keeps running on the machine it was built with, so a secret you add today never reaches a VM that predates it. That makes Update with Agent and New Setup Run a repair path rather than a cosmetic re-save, and it is the first cause to rule out when a run fails on a credential that plainly exists. The secrets fix path covers the other four.

Restore is what I would reach for when a setup run leaves a working environment broken. Put the last good version back first, then work out what the new one did.

Environment first, then network access, then the rest in whatever order suits you. Cursor puts environment setup ahead of every other recommendation in its cloud agent best practices, and most of what follows on this page assumes an environment that already runs.

Keeping those two apart matters because a blocked domain and a half-built environment fail the same way, somewhere in the middle of a setup run. Which is how an afternoon goes into a Dockerfile that was fine all along. Change both in one sitting and you have two suspects and nothing to tell them apart.

Prove one clean run before you tighten anything.

Agents reach the internet by default, so that first pass costs nothing on the network side. What you want out of it is the update script finishing and the repo behaving the way it would on a developer's machine.

Default settings decide what a run uses when it does not specify the choice itself, so they smooth out the most repetitive prompts. Each default does the following.

• Default model: the model used when a run does not specify one. Pick any model that supports Max Mode.
• Default repository: when empty, agents ask the user to choose a repo. Supplying a repo here lets users skip that step.
• Base branch: the branch agents fork from when creating pull requests. Leave blank to use the repository's default branch.

The Max Mode requirement reads like an arbitrary restriction until you know where it comes from. Cloud agents run in Max Mode. Cursor documents this on the automations side, where automations always run in Max Mode because they run as cloud agents, with no toggle to turn it off. The model you set here is therefore a spend decision as much as a quality one, since Max Mode bills at standard token rates and reads many more tokens per turn than an ordinary request.

Default repository cuts a step for a team that lives in one repo and quietly picks the wrong one for a team that does not, since a pre-filled field is, I suspect, the kind of default people accept without reading. Base branch can stay blank unless your team merges somewhere other than the repository default, in which case 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, and user and team settings support three modes. The table below maps each mode to what it permits.

Users, team admins, and environment owners can all configure network access. Environment-level settings can inherit user or team policy, add an environment allowlist, or define their own access mode.

Allowlist only is the tightest of the three and also the one that turns up your missing domains one failed run at a time, since nothing tells you a host was needed until something reaches for it. My instinct was to set it at team level and let people ask for exceptions. I would do it the other way round now. 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 starts failing after a tightening, check which hosts your install command reaches before anything else. Precedence between the user, environment and team scopes is its own puzzle, and the security and network page works through it.

All security options require admin privileges, and they govern how much of an agent's work is exposed and who can steer it. Here is what each toggle controls.

• Display agent summary: controls whether Cursor shows the agent's file-diff images and code snippets. Disable this if you prefer not to expose file paths or code in the sidebar.
• Display agent summary in external channels: extends the previous toggle to Slack or any external channel you've connected.
• Team follow-ups: controls whether team members can send follow-up messages to cloud agents created by other users on the team.

Switching Display agent summary off costs you the cheapest look at a run. Those file-diff images and code snippets are the fastest read on whether a run went anywhere useful, and once they stop appearing in the sidebar you have to open something to find out. I would make that trade on a repo where the file paths themselves are sensitive, and not across everything a team owns.

The external-channel toggle sits on top of the first one, so switching the summary off leaves it nothing to extend. Both are admin-gated, which means a developer who would rather not publish their diffs cannot make that call for themselves.

Team admins can enable or disable team-wide capabilities, and these changes save instantly and affect new agents immediately. Two features sit here: Long running agents, which controls whether team members can run agents for extended durations, and Computer use, which controls whether agents can use computer interaction capabilities and is available to enterprise teams only.

Team follow-ups let team members send follow-up messages to cloud agents created by other users on the same team, which helps when a teammate starts an agent and you need to course-correct or continue the work while they're unavailable. Team admins control this from the 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. security settings with three options, mapped in the table below.

The middle setting is the one I had to think about longest. The risk in that callout is specific to a run carrying a person's credentials, and a service account is a non-human Enterprise account that starts runs programmatically, off a Linear ticket or a Sentry error, with every team admin able to see the runs it creates. Confining follow-ups to those runs covers the case people actually want, because nobody is sitting in front of a job a ticket started, and it leaves a colleague's agent alone.

Team size decides the rest. On a team of five with the same repo access across the board, All costs you very little. At a few hundred people it reaches across access levels that the setting itself does not distinguish, which is reason enough to leave it on Disabled or service accounts.