How often is the underlying VS Code Extension API updated in Cursor?

Currently, Cursor v3.6 still appears to be using the VS Code Extension API v1.105.1. Within our organization, we rely on a custom extension for a DSL that is authored using Markdown files. A key feature of this extension stopped working starting with Cursor v2.5.

The same feature worked correctly in Cursor v2.4 and earlier, but it has remained broken through the subsequent releases up to the current v3.6 version.

Because of this, I’m trying to understand:

  • How often does Cursor update the underlying VS Code Extension API?

  • Is there a roadmap or schedule for syncing with newer VS Code versions that is publicly available?

Any guidance regarding this would be appreciated.

Thanks

There’s no fixed schedule or public roadmap for syncing Cursor with newer upstream VS Code releases. We periodically review upstream updates, and we update the runtime (Electron, Node.js, Chromium) and security patches independently on our own cadence, but full editor rebases don’t happen on a set timeline.

One thing worth clarifying about the version line you’re seeing: VS Code Extension API: 1.105.1 is the declared API compatibility version. It doesn’t always line up one-to-one with the underlying editor internals, which can sit on an older base. So an extension that depends on actual behavior from a newer VS Code build (rather than just the declared API level) can hit mismatches even though the API version reads 1.105.1. That’s a plausible candidate for what changed for your DSL extension around v2.5.

To dig into the regression, could you share a few specifics so we can investigate and, if it’s on our side, track it down?

  1. Which VS Code API or feature the broken functionality relies on (e.g. MarkdownString rendering in hovers/tooltips, a webview, language or diagnostic APIs)

  2. What happens now vs. in v2.4 - any error text, and what the feature is meant to do

  3. The engines.vscode value from your extension’s package.json

  4. If possible, a minimal snippet or example that triggers it

Two built-in places that usually surface extension errors: the Developer Tools console (Help > Toggle Developer Tools > Console) and the Extension Host logs (View > Output, then choose Extension Host from the dropdown). Anything that appears there when the feature fails would help a lot.

With those details we can take a proper look and file it if it’s a regression on our end.

Hi Mohit,

  1. VS Code API and regression

    The feature does not use webviews, markdown preview, or MarkdownStrin.

    It uses:

    • Custom command: script-a-rest.findFileReference

    • Custom LSP request: script-a-rest/findFileReferences (via vscode-languageclient)

    • Built-in workbench command: editor.action.showReferences to show results

      The server returns correct Location[] data; the client maps them to vscode.Location and calls editor.action.showReferences(anchorUri, anchorPosition, locations). On affected builds, that last step runs but the references UI never appears for .md targets. That points to a workbench/reference-peek regression in the 1.105.x generation, fixed upstream in VS Code after 1.110.x — not an undeclared API dependency.

  2. Feature and Regression Behaviour
    Find Script/CSV References
    (Ctrl+Shift+R / Explorer context menu) finds workspace usages of a script (.md) or data (.csv) file inside SaR markdown scripts.

    Example: main.md contains ExecuteCSV data/cars.csv Using scripts/test_cars.md and the same for test_cars_again.md. Finding references to cars.csv should show 2 hits in main.md; finding references to test_cars.md or test_cars_again.md should show 1 hit each.

    Regression: from VS Code 1.105.x and Cursor v2.5 onward, .md targets fail silently — no peek, no References view, no error. .csv targets still work. VS Code fixed this after 1.110.x; Cursor (still on API 1.105.1) has not. I debugged the extension: the LSP request completes and returns the correct locations; the client receives them

    Scenario VS Code v1.105.x VS Code after v1.110.x Cursor v2.4 and prior Cursor v2.5 to Current ( v3.6)
    Find refs to .csv Works Works Works Works
    Find refs to .md Broken Works Works Broken
  3. The engines.vscode value from your extension’s package.json:"^1.75.0"

  4. How to reproduce:

    • Create a folder and add:
      scripts_example/
      ├── main.md
      ├── data/
      │ └── cars.csv
      └── scripts/
      ├── test_cars.md
      └── test_cars_again.md

    • main.md:
      ```cs

      ExecuteCSV data/cars.csv Using scripts/test_cars.md

      ExecuteCSV data/cars.csv Using scripts/test_cars_again.md
      ```

      Note: Ensure the triple backticks with ‘cs’ is there. data/cars.csv and the two script files can be empty placeholders.

    • Install the attached VSIX (

      Script-A-Rest-0.7.0.zip (1.6 MB)

      ), open scripts_example as the workspace folder, then:

      1. Right-click data/cars.csvFind Script/CSV References → should show 2 references in main.md

      2. Right-click scripts/test_cars.md → same command → should show 1 reference in main.md

      On current VS Code (after 1.110.x), both steps should pass. On current Cursor (v3.6), step 1 should pass and step 2 should fail with no UI and no error.