Electron 38 — when and how should I migrate?
Determine whether to remain on Electron 38 after its end-of-life date or move to a supported major before security and Chromium drift become operationally unacceptable.
Blockers
- requires_version: package/electron-38 → engine/chromium-140
- requires_version: package/electron-38 → runtime/nodejs-22.18.0
- requires_version: package/electron-39 → engine/chromium-142
- requires_version: package/electron-39 → runtime/nodejs-22.20.0
- requires_version: package/electron-40 → engine/chromium-144
- requires_version: package/electron-40 → runtime/nodejs-24.11.1
- requires_version: package/electron-41 → engine/chromium-146
- requires_version: package/electron-41 → runtime/nodejs-24.14.0
- Deprecation of the --host-rules command-line switch
- window.open popups always being resizable
- NSAudioCaptureUsageDescription requirement for desktopCapturer on macOS 14.2 and later
- Shared-texture OSR paint event data structure change
- Deprecation of direct clipboard API access from renderer processes
- macOS dSYM archives changed from dsym.zip to dsym.tar.xz
- Deprecation of showHiddenFiles in Linux dialogs
- PDFs no longer create a separate WebContents
- Cookie changed event causes were updated
Who this is for
- enterprise
- small-team
- compliance
Candidates
Remain on Electron 38 temporarily with explicit risk acceptance
As of 2026-04-03, this is already a post-deadline hold position, not a supported steady state. Electron's support policy covers only the latest three stable major versions, and Electron 38 reached end of life on 2026-03-10. The release schedule lists Electron 38 on Chromium 140 and Node.js 22.18.0, while supported lines have already moved on to Electron 39, 40, and 41. Use this only as a short containment window while an upgrade is actively in flight.
When to choose
Use only when a release-blocking regression or native module issue makes an immediate upgrade unsafe. The decisive factor is whether you can tolerate running outside Electron's supported majors for a brief, time-boxed period.
Tradeoffs
Lowest immediate engineering disruption, but it leaves you outside the supported release set and increases exposure to Chromium and Electron security drift.
Cautions
As of 2026-04-03, Electron 38 is no longer supported. Do not treat the latest 38.x patch as an acceptable medium-term platform baseline.
Upgrade to Electron 39 as the smallest supported step
Electron 39 is still supported as of 2026-04-03, but only until 2026-05-05. The release schedule lists Electron 39 on Chromium 142 and Node.js 22.20.0, which keeps you on the Node 22 line and reduces runtime churn versus Electron 40 or 41. The main blocker-level changes documented for 39 are deprecation of the `--host-rules` command-line switch, `window.open` popups always being resizable, a new `NSAudioCaptureUsageDescription` requirement for `desktopCapturer` on macOS 14.2 and later, and a shared-texture OSR paint event data structure change. This is a bridge release, not a durable destination.
When to choose
Use when you need the lowest-churn supported hop from Electron 38 and want to avoid the Node 24 jump immediately. The decisive factor is whether a support window ending on 2026-05-05 is long enough for your next planned upgrade.
Tradeoffs
Smaller migration surface than Electron 40 or 41, but the remaining support runway is extremely short.
Cautions
Do not stop at Electron 39 unless you already have a near-term second hop planned. For macOS capture features, missing `NSAudioCaptureUsageDescription` becomes a deployment blocker.
Upgrade to Electron 40 now as the practical default target
Electron 40 is supported as of 2026-04-03 through 2026-06-30. The release schedule lists Electron 40 on Chromium 144 and Node.js 24.11.1, which buys more runway than Electron 39 while avoiding the newest-major jump to 41. The documented blocker-level changes for 40 are deprecation of direct `clipboard` API access from renderer processes, macOS dSYM archives changing from `dsym.zip` to `dsym.tar.xz`, and deprecation of `showHiddenFiles` in Linux dialogs. Electron 40 is the most balanced choice if you want a supported landing zone without adopting the very latest major immediately.
When to choose
Use when you need materially better support runway than Electron 39 and can absorb the Node 24 transition now. The decisive factor is whether your app, tooling, and native modules are already ready for the Node 24 baseline.
Tradeoffs
Longer support window and fresher Chromium than Electron 39, but a larger platform jump because Node moves from 22 to 24.
Cautions
Audit any renderer code that imports `clipboard` directly, and update symbol-processing pipelines that assume `dsym.zip` artifacts.
Upgrade directly to Electron 41 for the longest current support runway
Electron 41 became stable on 2026-03-10 and is supported through 2026-08-25. The release schedule lists Electron 41 on Chromium 146 and Node.js 24.14.0, making it the freshest supported line available as of 2026-04-03. The main documented breaking changes are that PDFs no longer create a separate `WebContents`, and cookie `'changed'` event causes were updated. If you are already paying the cost to leave Electron 38, Electron 41 maximizes time before the next required major upgrade.
When to choose
Use when security runway and reducing repeat upgrade work matter more than minimizing near-term change. The decisive factor is whether your app depends on PDF-specific `WebContents` handling or cookie-change event semantics that need explicit retesting.
Tradeoffs
Best support runway and newest Chromium/Node combination, but highest immediate regression-testing burden.
Cautions
Re-test any code that identifies PDFs via separate guest `WebContents`, and verify analytics or state machines that depend on cookie change-cause values.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Electron 38 — when and how should I migrate?"