Administrative policy exists in two forms: as a decision and as a fact on the machine. The decision is made in the console and looks complete; the fact occurs when the application on a particular laptop has read the rule and started following it. Between those states lies delivery, and delivery is handled by device management tools, the registry with group policies, configuration profiles and the policy file. Until delivery is described, any policy remains an intention.
The naive approach looks reasonable: write an instruction, send it around and ask everyone to set the required options themselves. On ten machines it works, because all ten people sit together, install the same version on the same day and remember why it was done. The approach is cheap and needs neither infrastructure nor approvals, which is exactly why it is stretched further than it should be.
It breaks quietly and in four places at once. A user setting is edited by the user, and editing it back leaves no trace. A new machine arrives clean, and by then the instruction is already out of date. Versions drift apart, because everyone updates when it suits them. And above all, the state of the fleet stops being known: to the question of how many machines have login under a personal account closed off there is no honest answer, only a guess.
The professional mechanism separates two things: delivery of the application and delivery of the rules. Both flows go through a device management tool - Jamf, Intune, Kandji - which installs the build and applies the policy across the fleet. The policy has three transports and one set of keys: on Windows the rules arrive through the registry via group policy, with the administrative templates placed next to the system ones; on macOS through a configuration profile; on Linux through a policy file in the user's home directory, which the application reads starting from version 2.0. Only the way of placing the value differs, the meaning of the keys is the same in all three cases.
The set itself is small and aimed at the essentials: allowed extensions, allowed team identifiers for login, the extension gallery address, an HTTP/2 disable toggle, the update mode and the workspace trust flag. The allowed teams key is the most important of them. It is what makes a corporate build corporate: the editor cannot be logged into with a personal account, and company data does not leave into somebody else's contract through that same editor.
Policy is worth distinguishing from the permissions file, even though the two live side by side. Permissions are set by a file at the user level and by the same kind of file in the repository, and they describe something else: the list of shell commands that run without approval, the list of tools of the tool connection protocol with masks such as server:tool and server:*, and the text instructions for the auto-review classifier. Policy answers the question of what may be installed and where one may log in. Permissions answer the question of what the agent does without asking. The layers differ: policy is set by the fleet administrator, while the permissions file is maintained by the team and the repository - yet it is rolled out through the same device management tool, and the administrative console's settings override the file's values.
A separate axis is versions, and it has two boundaries. The minimum supported version produces a warning that can be dismissed and work continues. The minimum allowed version cannot be dismissed: the upgrade becomes mandatory. Both boundaries are counted from the general release of a version and stand about a month apart, roughly two months to the first and roughly three to the second. The point of the construction is that the upgrade window is known in advance, which is why upgrading is planned as regular work rather than as a reaction to the day the editor stopped letting people in.
The worst spot is updates and administrator rights. On macOS an update requires administrator privileges, and a developer in a tightly managed fleet usually does not have them: the prompt appears, leads nowhere and returns. The way out is to separate the roles. The new build is delivered by the device management tool, while the prompt inside the application is silenced by the update mode policy set to its disabled value. The version then travels centrally and predictably, and the developer neither picks the moment nor hunts for someone with the password. On Windows the same task is solved with silent installation flags, and the initial rollout and the update fold into one set of commands. Below is that set:
The result is verified not on the administrator's machine but on the image of an ordinary developer without elevated rights, and verified by behavior rather than by the presence of a file. Try to log in with an account of a foreign team and confirm the login is rejected. Install an extension outside the allowed list and see it refused. Wait for an update and confirm it arrived without a single dialog. The network is checked separately: a closed proxy must pass the addresses of the product's backend, of downloads and updates, of the extension gallery, and the addresses of third-party model providers, otherwise a correctly deployed build turns out to be unusable for a reason that has nothing to do with policy.
The typical failures are predictable. Testing the policy on the administrator's machine, where everything is allowed without it anyway. Assuming policy replaces the permissions file and leaving the agent free to run commands. Leaving the update mode at its default where people have no administrator rights, and getting an endless prompt with no outcome. Rolling out the build without opening the required addresses on the proxy. Learning about the minimum allowed version on the day work is already blocked. And writing a key the application does not know into the policy file, taking the absence of an error for an applied rule.
# Installing the command-line interface; the editor is delivered by the device management tool
curl https://cursor.com/install -fsS | bash
# Windows: silent installation, no dialogs, no restart, with a log
CursorSetup-x64-2.0.exe /SILENT /VERYSILENT /SUPPRESSMSGBOXES ^
/NORESTART /CLOSEAPPLICATIONS /LOG=install.log
# Windows: updating an existing installation requires the /update flag
CursorSetup-x64-2.0.exe /VERYSILENT /update="%TEMP%\cursor-update.flag" ^
/CLOSEAPPLICATIONS /LOG=update.log
# Windows: the policy template goes next to the system ones,
# the language file into the locale subdirectory
copy cursor.admx C:\Windows\PolicyDefinitions
copy cursor.adml C:\Windows\PolicyDefinitions\en-US
# macOS: the same keys arrive as a configuration profile through the device management tool
# Linux: the policy file, read by the application starting from version 2.0
cat > ~/.cursor/policy.json <<'JSON'
{
"AllowedTeamId": "1,3,7",
"UpdateMode": "none",
"WorkspaceTrustEnabled": true
}
JSON