I have updates deliberately disabled, because I cannot afford to keep dealing with newly introduced bugs.
Yesterday, I noticed that the way cursor settings behaves, suddenly changed EVEN THOUGH I DID NOT UPDATE ANYTHING.
I use more than 1 laptop in development, they’re all suffering the same change, and they all stull have the old cursor versions 3.11 and older 3.12
Steps to Reproduce
View your settings in an older version.
SHOULD NOT SAY “Customize” in there.
Expected Behavior
DO NOT UPDATE OUR IDE WITHOUT OUR CONSENT
Operating System
Windows 10/11
Version Information
3.11 and 3.12 at least.
Additional Information
This is about the fact you changed our IDE without our permission.
The fact that the change you made is also unwanted as well, is a different issue.
Hey, thanks for the report. I’ll break it down since there are two separate things here.
First, you didn’t get an update. Your Cursor version didn’t change, and auto-update is still disabled, just like you set it. What you noticed isn’t a new build.
What actually happened is that some UI changes roll out server-side via feature flags, so the UI can change without updating the app itself. That’s how the Customize banner showed up in settings. The code for it was already in your current build in a dormant state, and the rollout just turned on its visibility.
Important for your setup: at this stage, the old tabs Rules / Plugins / Tools & MCPs / Hooks haven’t gone anywhere. The banner only links to the new Customize page, but the old tab content is still available under the banner, so you can keep using it like before.
On the “you’re changing the IDE without our consent” point, that’s a fair concern, and I’ll pass it on as feedback about the rollout mechanism. For UX feedback about the new page, including MCP, it’s better to keep that in your second thread so we don’t split the discussion: New "Customize" feature is unwanted and major usability backwards step
One quick question: you said this change affected all laptops. Do any of them have noticeably older Cursor versions installed? That would help us understand what’s going on.
Thanks as always for the really quick replies! My other laptop was on 3.10.20 and is not affected.
I recently downgraded to 3.11.25 because of the new MCP caching bug (but I have a VM on my laptop still on 3.12.17) - both of those changed.
I think it should go without saying, but worth stressing again: customers with "update.mode": "none",
in their settings would really appreciate it if your team were to honour that setting - regardless of how you want to ship it. Cursor already reminds us when it’s time to update, and cuts us off if we leave it too long: that’s all fine - forcing it upon us without consent or warning is not appropriate.
Thanks for clarifying the machines, that helps. So 3.10.20 stayed the same, and both 3.11.25 and the VM on 3.12.17 showed the change. Like I said, the build itself didn’t update and the versions didn’t move. Only the visibility of part of the UI changed via a server-side rollout.
On your main point, I agree the difference matters. Right now "update.mode": "none" only applies to updating the app itself, meaning the binary and auto-update, not to server-side flags that can enable UI that’s already shipped in the current build. For users who intentionally pin a version so nothing changes, expecting the UI to stay stable is totally reasonable. I’ll pass this to the team as feedback on the rollout mechanism. I can’t promise timelines or changes, but if there’s an update on this, I’ll reply here.
At the moment, the old tabs Rules / Plugins / Tools & MCPs / Hooks are still there. They’re still available under the banner, so you can keep your current workflow.