Updated October 21, 2026: re-tested on the latest releases, Cursor 3.26.13 and Postman 12.33.2 (first tested on Cursor 3.1.15 and Postman 11.93.0). The results did not change.
Cursor, Postman and the Claude desktop app are all built on the same framework, Electron (like VS Code, Slack and Discord), but they lock it down very differently. On my Mac, Claude 3.1623.0 turned on all six hardening switches I checked, Postman 12.33.2 turned on one, and Cursor 3.26.13 turned on none.
Those switches decide whether another program on your machine can quietly run code with the app's identity, permissions and signed-in sessions. Checking them took one read-only command per app and no special access.
What are Electron fuses?
Fuses are on/off switches written into an Electron app's framework binary when the app is packaged. Unlike settings in the app's code, they can't be changed at runtime, so they are a cheap, reliable way to remove risky features before shipping.
The six I checked, and the safe setting for each:
| Fuse | Safe setting | Why it matters |
|---|---|---|
| RunAsNode | Off | When on, setting ELECTRON_RUN_AS_NODE makes the app's binary act as a plain Node.js runtime |
| EnableNodeOptionsEnvironmentVariable | Off | When on, the NODE_OPTIONS variable can inject code or flags at startup |
| EnableNodeCliInspectArguments | Off | When on, --inspect flags can attach a debugger to the app's main process |
| EnableCookieEncryption | On | Encrypts the app's stored cookies with a key from the OS keychain |
| EnableEmbeddedAsarIntegrityValidation | On | Checks the app's packaged code against a hash before loading it |
| OnlyLoadAppFromAsar | On | Refuses to load app code from anywhere except the verified archive |
Electron's own security guidance recommends this hardened configuration; it is not the framework's default, so each vendor has to opt in.
How I checked
I used REA (Reverse Engineer Anything), an open-source MCP server, driven from Claude Code. Its inspect_electron_fuses tool finds the fuse block inside each app's Electron Framework binary and reports every fuse's raw byte.
- Read-only: it reads the shipped files; it doesn't launch, modify or bypass anything.
- Every architecture: Claude and Cursor ship universal binaries; the x86_64 and arm64 slices matched.
- Reproducible: each result carries the binary's SHA-256 and the fuse block's file offset, so anyone with the same version can verify it.
Versions tested on macOS 15.1 on October 21, 2026: Claude 3.1623.0, Cursor 3.26.13, Postman 12.33.2 (arm64 build).
Results: Cursor vs Postman vs Claude security scorecard
Claude passed every check, Postman passed one, and Cursor passed none.
| Fuse (safe setting) | Claude 3.1623.0 | Cursor 3.26.13 | Postman 12.33.2 |
|---|---|---|---|
| RunAsNode (off) | Off ✓ | On ✗ | On ✗ |
| NODE_OPTIONS allowed (off) | Off ✓ | On ✗ | On ✗ |
--inspect flags allowed (off) |
Off ✓ | On ✗ | Off ✓ |
| Cookie encryption (on) | On ✓ | Off ✗ | Off ✗ |
| ASAR integrity check (on) | On ✓ | Off ✗ | Off ✗ |
| Only load from ASAR (on) | On ✓ | Off ✗ | Off ✗ |
| Score | 6/6 | 0/6 | 1/6 |
- Claude ships the full hardened set.
-
Cursor leaves every switch at its permissive setting, including debugger attachment through
--inspect. -
Postman blocks
--inspectbut leaves the other five open.
All three leave GrantFileProtocolExtraPrivileges on; I left it out of the score because disabling it can break apps that load local files.
Verify it yourself
You don't have to trust REA or me. Electron's own fuse tool reads the same bytes, and it gives identical results:
npx @electron/fuses read --app /Applications/Cursor.app
npx @electron/fuses read --app /Applications/Postman.app
npx @electron/fuses read --app /Applications/Claude.app
On Cursor 3.26.13, for example, it prints:
RunAsNode is Enabled
EnableCookieEncryption is Disabled
EnableNodeOptionsEnvironmentVariable is Enabled
EnableNodeCliInspectArguments is Enabled
EnableEmbeddedAsarIntegrityValidation is Disabled
OnlyLoadAppFromAsar is Disabled
Claude 3.1623.0 shows the opposite on all six, and Postman 12.33.2 differs from Cursor only on EnableNodeCliInspectArguments (Disabled). The command only reads the app's files; it doesn't run or change anything. If you have different versions, your results may differ, which is the point of checking.
Is Cursor safe to use? What the results actually mean
Yes, for most people Cursor is safe to use. These gaps don't let anyone break into your Mac; an attacker already needs code running as your user. What they change is what that code can do next.
- Borrowed identity: code started through a permissive app runs as that signed app, so it can inherit macOS permissions you granted the app (files, camera, microphone) instead of triggering a fresh prompt.
- Quiet persistence: with integrity checks off, modified app code can load without warning the next time you open the app.
- Session exposure: with cookie encryption off, the app's stored web sessions are easier to read off disk.
The Cursor result has context. It's built on VS Code, whose extension host has historically depended on running Electron as Node, so turning RunAsNode off isn't a one-line change. That explains it; it doesn't make the other five settings necessary.
Vendors usually rate this class as low severity, and I agree it's hardening rather than an emergency. It still matters for an AI code editor and an API client: both hold source code, API keys and tokens.
Which threat do fuses protect against?
Added after a good question in the comments from @alexcodebytes.
The attacker that matters here is malware already running on your Mac as you, but without the macOS permissions you've granted to specific apps (Full Disk Access, camera, microphone, folders). It has two ways to get those permissions:
| Attacker's move | What stops it on modern macOS |
|---|---|
| Modify or replace the app's files | App Management (macOS 13 Ventura and later) blocks other programs from changing signed apps in /Applications without your approval |
Borrow the unmodified app, for example by launching it with ELECTRON_RUN_AS_NODE=1 or NODE_OPTIONS
|
Only the RunAsNode and NODE_OPTIONS fuses |
Borrowing is the quieter attack. The app stays signed and unmodified, so macOS sees the real app running and applies its permissions, with no prompt. That's why those two fuses matter even on a well-protected Mac.
The ASAR integrity fuses cover the first row where App Management doesn't apply: older macOS versions, and Windows and Linux, where nothing else stops a user's own processes from editing the app's code. The fuses do little against malware that already has admin rights, or against an attacker who can change the app before it's signed.
How to check the security of any Electron app
You can run the same check in a minute, with or without an AI agent.
-
Find Electron apps: any app with
Contents/Frameworks/Electron Framework.frameworkinside its bundle is Electron. -
Read the fuses:
npx @electron/fuses read --app /Applications/<App>.app, or ask an agent with REA installed to runinspect_electron_fuseson the app. - Compare against the safe settings in the table above.
If you ship an Electron app, flip the fuses at package time with @electron/fuses (Electron Forge and electron-builder both support it). Turn on ASAR integrity and OnlyLoadAppFromAsar together, and test your auto-updater and any native modules after each change.
Electron security checklist for developers
If you ship an Electron app, these are the fuse settings to aim for:
- [ ] RunAsNode off (unless you truly need it, as VS Code-based editors do)
- [ ] NODE_OPTIONS and
--inspectarguments off - [ ] Cookie encryption on
- [ ] Embedded ASAR integrity validation on
- [ ] OnlyLoadAppFromAsar on
- [ ] Re-check the fuses in CI on every release build
FAQ
Is Cursor safe?
For everyday use, yes. The missing hardening only matters if malware is already running on your computer; it then makes it easier for that malware to act as Cursor and use Cursor's permissions.
Is Postman safe?
Same answer as Cursor: these are hardening gaps, not a remote vulnerability. Postman blocks debugger flags but leaves the other five fuses at their permissive defaults.
Is the Claude desktop app more secure than Cursor?
On these six Electron fuses, yes: Claude enables every recommended setting and Cursor enables none. Fuses are one layer of security, not a full audit.
How do I know if an app uses Electron?
On macOS, right-click the app, choose Show Package Contents, and look for Contents/Frameworks/Electron Framework.framework.
What is RunAsNode in Electron?
A fuse that, when on, lets the ELECTRON_RUN_AS_NODE environment variable turn the app into a plain Node.js runtime that runs any script under the app's identity.
What's next
This is the first in a series of teardowns of everyday desktop apps. Next, I'll follow how one of these apps moves data between its web page and the operating system, through the preload script and IPC.
If you build an Electron app and want the same check run on it, with a short report, get in touch. Subscribe to get the next teardown.
Top comments (5)
The "low severity, but still matters for an AI code editor" framing is exactly right. These fuses don't let an attacker break in — they just make it easier for malware that's already on the machine to borrow Cursor's identity.
For a developer tool that holds source code and API keys, "borrowed identity" is a bigger deal than for a regular app. If malware can run as Cursor, it inherits Cursor's file access and session cookies without triggering a new macOS permission prompt.
Curious if you've tested what happens when Cursor auto-updates. Does the update process re-write the fuses (back to permissive), or does it preserve the vendor's settings?
@alexcodebytes Thanks, great question! Updates don't reset the fuses. They're baked into the Electron binary each release ships, so you get whatever the vendor built. I actually checked: Cursor 3.1.15 and 3.26.13 (latest) have identical fuse settings, so they've been carried forward unchanged. Since ASAR integrity checks are off, though, nothing stops the app's code from being modified on disk between updates.
"That's the part that actually matters" — if ASAR integrity is off, then the fuses are just a suggestion. An attacker who can write to the app bundle can swap the ASAR, and the fuses won't complain.
The interesting question isn't "are the fuses good or bad", it's "what threat model are they defending against". If the threat is "malware running as the user", then fuses don't help — the malware can just replace the app. If the threat is "malware running as a different user", then fuses might help, depending on the OS.
Curious if the article covers that distinction.
Fair point, and you're right that the threat model is the real question. On modern macOS, though, same-user malware can't just replace the app: since Ventura, App Management blocks other processes from modifying signed apps in /Applications without your approval. So the realistic attack is borrowing the app, not swapping it. Launch it with ELECTRON_RUN_AS_NODE and you get its signature and macOS permissions (files, camera, mic) with no prompt. That's exactly what the RunAsNode and NODE_OPTIONS fuses block. ASAR integrity matters more where App Management doesn't apply, like older macOS, Windows and Linux. I've added a short threat-model section to the post based on your question, thanks!
"Borrowing the app, not swapping it" is the perfect way to describe it, and it's exactly why
RunAsNodeis the most dangerous fuse.If an attacker can launch Cursor with
ELECTRON_RUN_AS_NODE, they don't need to modify the app bundle — they just need to run their own code with Cursor's identity. That's a much lower bar than "get past App Management".Curious if you've tested whether the
ELECTRON_RUN_AS_NODEattack actually works on a modern macOS with Cursor installed. Asking because "it should work" and "it works" are different things.