Chinese IME Backspace during pinyin composition deletes already-committed text in files

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After a recent Cursor update, when editing Markdown in Source view: while composing Chinese pinyin (underlined composition), pressing Backspace to delete some pinyin letters also deletes already committed Chinese/text that was already in the document.

This does NOT happen in:

  • Markdown Preview editing surface
  • Cursor Chat input
  • Browser text fields
  • System apps (Notes, etc.)

So it is specific to the Monaco Source editor input path, not the IME app itself.

Steps to Reproduce

  1. Open any .md file in Cursor.
  2. Switch to Source view (not Preview).
  3. Type and commit some Chinese text (e.g. 需要首先拟定).
  4. Start a new pinyin composition (e.g. type lunwen without confirming).
  5. Press Backspace several times to delete part of the pinyin.
  6. Observe: committed document text before the caret is also deleted.

Expected Behavior

Backspace during IME composition should only modify the current composition string (pinyin), not previously committed document text.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.18.9
VSCode Version: 1.128.0
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Electron: 40.10.3
Chromium: 144.0.7559.236

For AI issues: which model did you use?

  • N/A (editor IME bug, not model-related)

Additional Information

  • Reproduces with both Apple 简体拼音 and 微信输入法 → not a single IME vendor bug.
  • Reproduces with Cursor --disable-extensions → not an extension.
  • Tried editor.experimentalEditContextEnabled / editor.editContext both true and false → no fix.
  • Disabling Markdown inline suggestions / Cursor Tab removed ghost text, but did not fix the deletion bug.
  • Markdown Preview surface is fine; only Source is broken. Strong signal that Monaco composition/backspace handling regressed after update.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the detailed report and the recording. That really helps.

To narrow down the cause, can you help with a couple of things?

  1. Does the same thing happen in a non-markdown file, like a plain .txt or .py, or only in .md in Source mode? This is key since it will show whether it’s a Monaco issue in general or something markdown-specific.

  2. What Cursor version were you on before the update when this started?

  3. When you changed editor.editContext / editor.experimentalEditContextEnabled, did you fully restart Cursor after each change? These settings only apply after a restart, so it’s important to confirm the result with a restart between toggles.

I get that this is really disruptive when typing in Chinese. Reply with those three details and we’ll keep digging.

Thanks for the follow-up — here are the details:

  1. File type scope
    I mainly hit this in Markdown Source mode (Preview is fine).
    I also just checked non-markdown files:
  • .txt: [YES reproduces ]
  • .py: [YES reproduces ]
    So it looks like a general Monaco/editor IME issue.
  1. Version before the update
    From local update logs:
  • Before: Cursor 3.17.21 (running through Aug 29)
  • Update prepared/applied early Aug 30 → Cursor 3.18.9
    Current: 3.18.9 (VSCode 1.128.0, Electron 40.10.3, Chromium 144, macOS 26.4.1, Apple M3)
  1. editContext restart method
    Important correction: when toggling
    editor.editContext / editor.experimentalEditContextEnabled,
    I used command+p for Cursor quit + relaunch.

Also still true from the original report:

  • Reproduces with Apple Pinyin and WeChat IME
  • Reproduces with Cursor --disable-extensions
  • Chat input / browser inputs are fine; Markdown Preview editing is fine

Thanks, these details really help. Since the issue happens in .txt, .py, and .md Source view, and with two different IMEs, that’s a good sign it’s in Monaco’s general editor input path, not something specific to Markdown or a particular IME. Also, you’ve got a clear window where it worked on 3.17.21 and broke on 3.18.9. This shouldn’t happen, and it’s definitely not something in your setup.

I’ve shared everything, including the details and the video, with the team. I can’t give an exact timeline yet, but I’ll reply in the thread as soon as there’s an update.

For now, if this is seriously blocking your work, a temporary workaround is to roll back to 3.17.21 where the issue didn’t happen. Let me know if you need a link to the previous version.