: Request: Please bump the underlying VS Code Extension API / Electron version to the latest upstream release

Ideas Feature Requests
,
1

Feature request for product/service

Cursor IDE

Describe the request

Hi Cursor Team,

I want to advocate for an infrastructure sprint to pull in the latest upstream base releases. Currently, Cursor stable is drifting behind the cutting-edge version targets of the upstream ecosystem, which impacts extensibility and performance:

  • Our Current Environment: VS Code API 1.128.0 | Electron 40.10.3 | Chromium 144.0.7559.236 | Node.js 24.15.0
  • Upstream Latest: VS Code API 1.129.0 | Electron 43.2.0 | Chromium 150.0.7871.129 | Node.js 24.18.0 [1, 2, 3]

Below is the concrete technical case for why bumping Cursor to match these specific upstream releases will benefit both the engineering team and the user base:

1. Extension Compatibility Deficit (API 1.128 vs 1.129)

  • The Issue: Third-party marketplace extensions are aggressively updating their manifests to target VS Code 1.129+. Because Cursor is locked to 1.128, users are encountering installation failures or losing silent features when tools expect the newest 1.129 core layout APIs.
  • The Benefit: Bumping the extension engine to 1.129 natively prevents marketplace fragmentation and cuts down on manual overrides.

2. Upgrading to Electron 43 & Chromium 150

  • The Issue: Cursor relies heavily on rendering dense webviews (Composer, Chat panels, multi-file diffs) and heavy indexing. Electron 40 / Chromium 144 lacks the latest rendering optimizations, causing unnecessary memory bloating during deep AI contextual agent workflows.
  • The Benefit: Jumping to Electron 43.2.0 and Chromium 150 unlocks massive garbage collection improvements in the V8 engine and dramatically reduces rendering memory consumption. This translates directly to a cooler, faster IDE experience for developers with massive codebases.

3. Native Node.js 24 LTS Enhancements

  • The Issue: Cursor runs on an early runtime release (Node 24.15.0).
  • The Benefit: Updating to Node 24.18.0 (bundled natively with Electron 43) brings crucial backported security fixes and localized performance boosts to child processes. This speeds up internal CLI tasks, terminal spawns, and local workspace indexing.

4. Minimizing Technical Debt

  • The Issue: The longer Cursor stalls on older base frameworks, the more complex it becomes to safely backport features without creating deep merge conflicts.
  • The Benefit: Aligning with the latest 1.129 and Electron 43 releases right now streamlines future development cycles for your engineering team.

Cursor easily has the best AI execution of any editor. Keeping the foundation directly synchronized with the absolute latest upstream runtime ensures it stays the sturdiest, fastest environment on the market!
Are there plans to jump to 1.129 / Electron 43 in an upcoming stable update?

Operating System (if it applies)

MacOS

5

Hey, thanks for the detailed write-up. We don’t often see a feature request that’s this well thought out.

Syncing our base with upstream is something we invest in all the time. The Extension API target was bumped to 1.128 in mid-July. At that point 1.129 wasn’t even out yet. Upstream security fixes are backported continuously too. So the base will keep moving forward in the next releases.

A couple clarifications about the premise:

  • Electron 43 is not the upstream baseline for the editor. VS Code itself is moving to Electron 42, not 43. We intentionally track the Electron version used by upstream instead of jumping ahead. Every Chromium Electron bump has a real risk of regressions, and upstream absorbs that risk first. We’ve had a case before where we had to roll back a direct jump to E42 because of bugs in upstream itself.

  • The extension compatibility gap on 1.129 is still mostly hypothetical. 1.129 shipped about a week ago, and there are barely any extensions right now that strictly require engines.vscode >=1.129. If you hit a specific extension that won’t install only because of the engine version, send it over and we’ll take a separate look.

So we don’t need a separate infrastructure sprint here. This is already an ongoing process, and versions will be pulled in gradually. I can’t give an ETA for a specific release with 1.129.