Assertion error when using custom editors incl. markdown preview editors

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug Report: Custom Editors Fail to Open AI-Created Files Until Opened in Text Editor First (Cursor assertion error)

Summary

Custom editors (including custom editor providers via the VS Code API CustomTextEditorProvider, and other Markdown preview editors) cannot open files that were created by Cursor’s AI until those files have been opened at least once in the standard text editor. The operation fails with “Assertion Failed: Argument is ‘undefined’ or ‘null’”.

Key finding: Simply opening the file once in the text editor is enough to fix it - you don’t need to accept the diff, make changes, or save. This suggests Cursor is lazily initializing document state (for diff tracking), and custom editors bypass that initialization.

Environment

  • Cursor Version: [your version]
  • OS: macOS (darwin 25.1.0)
  • Extension: SlashMD (custom Markdown editor using CustomTextEditorProvider)

Steps to Reproduce

  1. Install any extension that provides a custom editor for .md files (e.g., SlashMD via CustomTextEditorProvider, or Markdown preview editors)
  2. Ask Cursor’s AI to create a new Markdown file (e.g., “Create a file called test.md with some content”)
  3. The AI creates the file and Cursor shows the diff view
  4. Try to open the newly created .md file using a custom editor (SlashMD, Markdown preview, etc.)
  5. Result: Error dialog appears: “Unable to open ‘test.md’ - Assertion Failed: Argument is ‘undefined’ or ‘null’”

Expected Behavior

The custom editor should be able to open the file, regardless of whether there’s a pending diff to review.

Actual Behavior

The custom editor fails to open with an assertion error. The file cannot be opened in a custom editor until the user opens it once in the standard text editor first. No other action is required - just opening it once is enough.

Workaround

Simply open the file once in the plain text editor first (right-click → “Open With…” → “Text Editor”). You don’t need to:

  • Accept the diff
  • Make any changes
  • Save the file

Just opening it once in the text editor is enough. After that, the custom editor works fine for that file.

Analysis / Evidence

The issue appears to be in how Cursor initializes document state for AI-created files (likely tied to diff tracking):

  1. When AI creates a file, Cursor tracks it for diff display but may not fully initialize the TextDocument state
  2. Custom editors are invoked through Cursor’s custom editor open pipeline, which fails before the provider is even called (assertion is thrown before resolveCustomTextEditor runs)
  3. Opening in the standard text editor triggers proper document initialization
  4. After that, custom editors work fine

Key observation A: The same newly created file also fails to open in other custom editors (e.g., Markdown preview editors) with the same assertion error. This suggests it’s not extension-specific.

Key observation B: Extension-level debugging shows the extension activates normally, but when the crash happens there is no call into the custom editor provider (no resolveCustomTextEditor), indicating the failure occurs inside Cursor before extension code can run.

Key observation C: Opening the file once in the built-in text editor resolves the issue without accepting the diff or saving, suggesting the text editor path is the one that initializes Cursor’s diff/document state.

Log Evidence (Renderer)

From Cursor’s renderer.log, when attempting to open an AI-created markdown file in a custom editor:

[error] Unable to retrieve document from URI 'file:///.../test/quick-reference.md'
  at Wss.getDocument (.../extensionHostProcess.js:...)
  at Fss.$resolveCustomEditor (.../extensionHostProcess.js:...)
...
[error] Error: Assertion Failed: Argument is `undefined` or `null`.
  at .../workbench.desktop.main.js:...

This strongly suggests the failure happens in Cursor/VS Code core before any custom editor provider is invoked.

Impact

This significantly impacts workflows where AI frequently creates or modifies files that have custom editor providers. Users must manually open each AI-created file in the text editor first before their preferred custom editor will work. This adds friction to AI-assisted workflows and defeats the purpose of having a default custom editor.

Suggested Fix

When AI creates/modifies a file, Cursor should fully initialize the TextDocument state immediately, not lazily on first text editor open. The document state should be consistent regardless of which editor type opens it first.

Specifically:

  1. Ensure document.getText() returns valid content for custom editors even if the file hasn’t been opened in a text editor yet
  2. The diff tracking/display should be separate from document materialization
  3. Custom editors should receive the same fully-initialized document that text editors do

Minimal Reproduction Extension

If needed, I can provide a minimal VS Code extension that reproduces this issue - it would just register a CustomTextEditorProvider for .md files and try to read document.getText().


Related: This may be related to other “phantom modifications” issues reported on the forum.

Steps to Reproduce

  1. Install a customer markdown editor or markdown preview extension.
  2. Have Cursor AI generate a markdown file.
  3. Try to open the markdown file with the custom editor BEFORE opening it with the default text editor.
  4. Observe assertion error - file won’t open.
  5. Open with default text editor. Close editor again.
  6. Try to open with customer editor again.
  7. Editor now opens file successfully.

Expected Behavior

Custom editor should open and display the newly generated file regardless of whether the file has been opened with the default text editor or not.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.34
VSCode Version: 1.105.1
Commit: 643ba67cd252e2888e296dd0cf34a0c5d7625b90
Date: 2026-01-10T21:17:10.428Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.1.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Key observation D: If you click “Keep” on the AI-created file (accepting it), before attempting to open it, the file opens in custom editors without issue. This suggests the bug is specifically in Cursor’s “keep/changed” state tracking — suggesting the document state is only fully initialized when the file is “kept” or when the text editor forces initialization as a side effect.

Hey, thanks for the report. This is a known issue with initializing the document state for AI-created files.

The team is already working on a fix. The bug showed up after Cursor 2.0 and affects custom editors (CustomTextEditorProvider) and the Markdown preview. The issue is that Cursor doesn’t fully initialize the TextDocument for AI-created files until you open it in the text editor at least once.

Workaround (2 options):

  1. Click Keep on the AI-created file in the review panel before opening it in your custom editor. Based on your observation D, this should fix it.
  2. If the file is already created, open it once in the text editor (right-click → Open With → Text Editor). After that, the custom editor should work.

Related threads:

Can you confirm whether the Keep option works on your side?

Hey, thanks for the report. This is a known issue with initializing the document state for AI-created files.

The team is already working on a fix. The bug showed up after Cursor 2.0 and affects custom editors (CustomTextEditorProvider) and the Markdown preview. The issue is that Cursor doesn’t fully initialize the TextDocument for AI-created files until you open it in the text editor at least once.

Workaround (2 options):

  1. Click Keep on the AI-created file in the review panel before opening it in your custom editor. Based on your observation D, this should fix it.
  2. If the file is already created, open it once in the text editor (right-click → Open With → Text Editor). After that, the custom editor should work.

Can you confirm whether the Keep option works on your side?

Yes, those work, but many won’t figure this out so it should be fixed

1 Like