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?
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.
Now, it’s the 13th October, but Cursor is still at VS Code 1.128(upstream is now at 1.134) and the OP considerations are more relevant than before. Also VS Code 1.129 introduced the new editor UI, many extensions are being updated to support the new panels and UI, with some workbench customisation keys that are not compatible with v1.128 causing flashing colors.
On the base version, syncing with upstream is an ongoing process for us, and versions get pulled in gradually with releases. I can’t give an ETA for a specific version like 1.129+ or a specific Electron version, but that is the direction we’re moving in.
Separately, the flashing colors issue sounds like its own problem, and it would be better to look at it separately from the feature request. Could you share:
the exact keys in workbench.colorCustomizations where this happens
the extension that requires this, and its minimum engines.vscode
your Cursor version and a short video or screenshot showing the flashing
Best would be to open a separate thread for this in Bug Reports. That makes it easier to track this specific symptom, and we can take a closer look at it. If you share the details here too, I’ll still check it out.
Hey, there isn’t a new update yet. Nothing has changed since October 13. The codebase is being brought closer to upstream gradually, alongside releases. I can’t give an ETA for a specific VS Code API or Electron version.
What helps most here is concrete examples. If an extension can’t be installed or doesn’t fully work specifically because of engines.vscode, send its name and the minimum version it requires. Those cases can be looked at separately, without waiting for a broader bump.