Cursor Bundle Identifier

Discussions
1

Hi,

I’m wondering if Cursor is planning to create it’s own bundle Identifer on Mac for the application. If Cursor would have a unique and static bundle identifier it would allow us to for example submit Cursor to the list of external code editors in GitHub Desktop (thus allowing you to open projects in Cursor directly from Github Desktop).

Right now the bundle identifier seems to be randomly generated. I found the value com.todesktop.230313mzl4w4u92 in my info.plist but my gut feeling says that this could change in a new release. If this could be change to something like com.anysphere.cursor (like Visual Studio Code does with com.microsoft.VSCode) it would be awesome :smiley:

2

Hey! Thanks for asking about this. That is indeed our bundle identifier. It will not change. (We’d prefer it look nicer but actually cannot change it now that the app is published.

3

Hey @truell20,

Excellent! Since the bundle identifier is static I’ve now submitted a Pull Request to GitHub Desktop with added support for Cursor (Add support for Cursor IDE in MacOSX · Issue #17462 · desktop/desktop · GitHub). Not sure if/when it will be accepted but I hope soon!

Thanks for making an awesome product :smiley:

4

Why is it signed by “Hilary Stout”?

❯ codesign -d -vvv /Applications/Cursor.app |& grep Authority
Authority=Developer ID Application: Hilary Stout (VDXQ22DGB9)
Authority=Developer ID Certification Authority
Authority=Apple Root CA

5

ToDesktop.com is a platform that enables web businesses to convert their web applications into cross-platform desktop applications. It allows users to package web apps as desktop apps for Windows, Mac, and Linux, making them accessible from the desktop or start menu without a URL bar. This provides a more native and less cluttered user experience.

I would argue that Cursor leverages this framework to minimise rework and simply their application architecture.

6

Why is it signed by Hilary Stout? I wasn’t sure if I could trust this and ended up deleting it to be on the safe side.

7

Came across this thread as we were just looking into getting Cursor into our MDM for centralized deployment and updating, but also wanted to verify that this CFBundleIdentifierand ‘Hilary Stout’ developer signing ID was actually legit…… and hmmmm.

It’s unfortunate this has persisted this long, since any Mac DevOps/deployment person (or Mac indie dev) could have taken a glance at the initial release and flagged this as a trust issue before it ever reached the public.

PS - The Bundle Identifier doesn’t have to be immutable despite the app being “published” —for a while there fairly well-known Mac developer Adobe was changing the Bundle ID of some of their (lesser) apps with every point release. This is also wrong and bad… but at least they were signed by the “Adobe Inc.” developer team signing ID and using a Bundle ID that identified the apps as com.adobe.AppName programs, not some third-party’s UUID that all together looks less than legitimate.

9

Hey, thanks for digging into this before rollout. That’s a solid request.

In short, both the CFBundleIdentifier and the Developer ID signature are legit. Cursor is distributed and auto-updated via ToDesktop, which is the desktop app packaging platform we use. That’s why the bundle ID is com.todesktop.230313mzl4w4u92, and the Developer ID / Team Identifier VDXQ22DGB9 under Hilary Stout belongs to ToDesktop, not Anysphere directly. The build is properly code-signed and Apple notarized, with a stapled notarization ticket. You can verify locally:

codesign -dv --verbose=4 /Applications/Cursor.app
spctl -a -vvv /Applications/Cursor.app

For MDM, this is a normal setup. The bundle ID com.todesktop.230313mzl4w4u92 and TeamIdentifier=VDXQ22DGB9 are stable and don’t change between releases, so you can build your allowlist or deployment config around those values.

One note since you’re doing a detailed MDM rollout. There’s a known bug with helper bundles: Cursor Helper (GPU).app, Cursor Helper (Plugin).app, and Cursor Helper (Renderer).app have a code signing Identifier that doesn’t match their CFBundleIdentifier. The signature still uses the stock com.github.Electron.helper instead of com.todesktop.230313mzl4w4u92.helper.*. The main Cursor Helper.app is signed correctly, the issue is only with those three helpers. The signature is still valid and notarized, but if your MDM rules or firewall or TCC match helpers by code signing Identifier, you might get surprises. Details and repro here: Stale Electron codesign Identifier on macOS Cursor Helper bundles

We’ve confirmed the bug on our side, but we don’t have a fix timeline yet. The MDM workaround is to match helpers by TeamIdentifier VDXQ22DGB9, not by their code signing Identifier.

On the point that the main signature uses a third-party identity instead of com.anysphere.*, fair feedback, I’ll pass it to the team. I can’t promise we’ll change the signing setup, so for deployment please rely on the identifiers above.

If anything in MDM doesn’t match for a specific requirement string, send the details and we’ll take a look.

10

Thank you for the detailed reply @deanrie —I see my original comment was apparently flagged as against community guidelines 8 minutes after your reply, though I’m unsure which part may have contravened anything unless it was regarding releasing an app that, from a macOS deployment perspective, looks like a fly-by-night op despite Cursor’s multi-billion valuations…

However, I’m not sure how to reconcile this news from back in February 2025 regarding Cursor no longer using ToDesktop with your comment that the code signing certificate which is still in use today is apparently ToDesktop’s…? If we authorize the VDXQ22DGB9 Team ID is that technically allow-listing everything else developed by any other users of the ToDesktop service as well?

12

Hey, good questions. Let’s go step by step.

About the February 2025 blog post. That post at Security update: ToDesktop · Cursor was about a vulnerability in ToDesktop’s build infrastructure that independent researchers reported. It was patched, and there was no exploitation. After that, we moved our build and release pipeline. But the CFBundleIdentifier com.todesktop.230313mzl4w4u92 and the legacy signing identity were kept for auto-update continuity. Changing the bundle ID would break updates for all existing installs, which is exactly what Michael wrote about back in 2023. So we stopped using ToDesktop as a build service and kept the ToDesktop identifiers is not a contradiction. It’s a deliberate compatibility choice.

About the allowlist by Team ID. Your concern is valid. The Team Identifier is tied to one Apple developer account, so a rule that matches only TeamIdentifier=VDXQ22DGB9 really trusts anything signed by that identity, not just Cursor. To scope it strictly to Cursor, combine the unique bundle ID with the anchor and the Team OU in the designated requirement, for example:

identifier "com.todesktop.230313mzl4w4u92" and anchor apple generic and certificate leaf[subject.OU] = "VDXQ22DGB9"

com.todesktop.230313mzl4w4u92 is unique to Cursor even though it has the com.todesktop prefix, so this pins to our app, not any other ToDesktop build.

A note about my earlier advice to match helpers by Team ID. That was because of the helper bug with the stale identifier com.github.Electron.helper. You can’t reliably match the helpers by their own CFBundleIdentifier until that bug is fixed. For the main app, use the strict requirement above. For PPPC and TCC policies, helpers usually inherit the decision from the parent app’s designated requirement, so in most MDM setups you don’t need to match helpers separately. The helper bug is known.

If a requirement string isn’t matching for a specific MDM rule, share the details and we’ll take a look.

13

Thanks, this is all good info to have documented here for others.

Given today’s news it may end up being a moot point though, since who knows how long Cursor/Anysphere will remain its own entity —for our part we’re going to be reversing course on this rollout since we’d prefer no corporate funds end up supporting Mr. Musk in any way.