Cursor Automatic Updater

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Encountering an issue with in-app updates when running as a standard user. The updater is generating a temporary file which is blocked by our app-control. Cursor is deployed in an enterprise environment via MS Intune. When a standard user initiates an update from within the application, the updater runs under the user’s context and stages CodeSetup-stable-.exe under %LOCALAPPDATA%\Temp. Our app-control regards this location as insecure and the installer exe generated at the time is unsigned and not tagged as a managed-install. The update fails unless Cursor is launched with “Run as administrator” which is not practical for the environment. Any suggestions to approach this issue without compromising our app-control integrity would be appreciated.

Steps to Reproduce

Cursor is installed via Intune. App-control WDAC requires managed installs and install files cannot be executed from a user’s localappdata directory.

Expected Behavior

If CodeSetup-stable-.exe were signed, we could add the signature to the WDAC. If it were marked as part of the managed install, I would assume it would be allowed.

Operating System

Windows 10/11

Version Information

For Cursor 2.4.22 or higher.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report. This is a known issue. An Inno Setup based updater creates a temporary .exe or .tmp file during the update, and that file isn’t signed, so WDAC correctly blocks it.

There are a few workarounds, depending on how strict your WDAC policy is:

  • Publisher allow rule: Create a WDAC rule based on the publisher certificate of the main signed CursorSetup executable (signed by Anysphere via DigiCert). This avoids having to update hashes for every release.
  • Managed Installer rule: If you deploy Cursor via Intune, you can configure Intune as a WDAC Managed Installer. Then anything installed via Intune (and its child processes) is automatically marked as managed. This should also cover the update process, but it depends on how your supplemental WDAC policies are set up.
  • Disable auto updates and deploy via Intune: A more controlled approach is to disable Cursor’s built-in auto updater and fully manage version rollouts through Intune, using the full installer from Cursor · Download. This gives your team full control over the update cycle.

On signing, the team knows this is a gap. I can’t promise timelines, but reports like this help with prioritization, especially from enterprise or team accounts.

Let me know if you want more specific help with your WDAC setup.

Thanks for the reply. With our setup, I believe we satisfied the requirements for the publisher allow rule and also as a managed installation. We will take another look at our setup and verify that is correct.