Several Electron features rely on the operating system's view of a signed app. The Electron code signing guide names four that only behave correctly in signed apps: safeStorage, app.setLoginItemSettings(), the cookieEncryption fuse and autoUpdater. Test them with a signed build, not just a development one.
The four features
| Feature | What it does | Why signing matters |
|---|---|---|
| safeStorage | Encrypts and decrypts strings using OS facilities | Per the guide, behaves correctly only in signed apps |
| app.setLoginItemSettings() | Controls launch at login | Same |
| cookieEncryption fuse | Encrypts cookies on disk | Same |
| autoUpdater | Built in updater | Same; on macOS it needs a signed app |
The Electron guide states these behave correctly only in signed apps. The guide does not spell out the mechanism. A reasonable reading is that these features lean on the operating system recognizing the app's identity, which an unsigned or ad hoc build lacks.
What goes wrong in practice
- A value stored through
safeStoragein a development build may not behave the same way in the signed release, so do not assume it carries over. - A developer sees updates work on one machine and fail on another.
- A login item registers in testing and does not survive a real install.
These bugs often show up first in the field, since developers mostly run unsigned builds.
Test plan
- Build a signed release candidate for each platform on a real machine.
- Store a value with safeStorage, close the app, reopen and read it.
- Install over a previous signed version and confirm the updater path.
- Check launch at login after a reboot.
- Treat data written by a development build as disposable.
Do not store a secret you cannot recover
If a user can lose access to data after a reinstall or an identity change, design a recovery path. Do not rely on one local encrypted value for something users cannot recreate.
Security angle
These features are protections. If a build is unsigned, a platform may refuse to provide them, and teams sometimes work around that with weaker code, such as writing a token to a plain file. That workaround ships if nobody notices, so look for it in review.
Try it yourself
Click through the code scan demo and see how an insecure storage pattern would be flagged. Then picture the same check running on every pull request.
Click through it at your own pace, or open it full screen.
Quick check
Is safeStorage broken if my dev build fails?
Probably not. The guide says it behaves correctly only in signed apps. Test with a signed build.
Does signing remove the need for secure storage review?
No. Signing enables the platform features. You still decide what to store and how to recover it.
Safeguard's code scanning can flag insecure storage patterns in a pull request. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
