[Critical i18n] IME Enter key triggers unintended submission in Chat and AskQuestion — completely breaks CJK input for 1.5 billion users

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using Japanese/Chinese/Korean IME in the AskQuestion tool’s free-text input fields, pressing Enter to confirm character conversion (e.g., selecting kanji) unintentionally submits the entire form instead of just confirming the conversion.

Note: The Chat input field handles IME correctly. This bug is specific to the AskQuestion tool UI.

This bug has been reported since April 2024 and remains unfixed after nearly 2 years. It is a fundamental i18n failure caused by not checking KeyboardEvent.isComposing.

Why this is critical:

  • 1.5 billion people use CJK writing systems — all of them require IME where Enter confirms character selection
  • The AskQuestion tool is completely broken: Enter submits the entire multi-question form with garbled/incomplete answers, with no undo
  • Agent Skills using AskQuestion for interactive flows become unusable for CJK users
  • The fix is trivially simple (one boolean check), yet ignored for 2 years across 4 separate reports

Steps to Reproduce

  1. Use an Agent skill that calls the AskQuestion tool with multiple questions including a free-text input option
  2. Select the free-text input option in one of the questions
  3. Switch to Japanese IME and start typing (e.g., type “nihongo” → 日本語 appears as conversion candidate)
  4. Press Enter to confirm the conversion
  5. ACTUAL: The entire AskQuestion form is submitted immediately with incomplete/garbled answers for ALL questions — not just the one being typed in
  6. EXPECTED: Only the IME conversion is confirmed; the form remains open for the user to continue answering

Note: The Chat input field handles IME composition correctly. This bug is specific to the AskQuestion tool’s form UI.

Expected Behavior

Pressing Enter during active IME composition should only confirm the character conversion, not submit the form. This is standard behavior in every major application (VS Code editor itself, Slack, Discord, Google Docs, etc.).

The keydown handler should check event.isComposing === true and skip submission when the user is in the middle of IME composition.

Operating System

MacOS

Version Information

macOS 26.3 (Tahoe)
Cursor 1.1.6 (latest as of March 2026)
IME: macOS Japanese Input

For AI issues: which model did you use?

Not model-specific. This is a UI/input handling bug that affects all models. The AskQuestion tool UI is the primary affected component.

Additional Information

Root cause and fix:

The Enter keydown handler does not check event.isComposing. The fix is one line:

// Before (broken):
if (event.key === 'Enter') { submitForm(); }

// After (fixed):
if (event.key === 'Enter' && !event.isComposing) { submitForm(); }

MDN reference: KeyboardEvent: isComposing property - Web APIs | MDN

Previous reports (all closed without fix):

Four reports. Two years. One-line fix. Zero action. Please prioritize this.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report. You’re right, this is a bug, and the fix really is trivial (a missing isComposing check).

I can see this was already raised back in April 2024 (Unintended Prompt Submission During Japanese IME Conversion in Cursor Help Pane), and unfortunately it still hasn’t been fixed. I agree it’s really inconvenient.

I’ve escalated this to the team and linked your report with the previous ones. I can’t share a timeline yet, but your detailed analysis and the exact spot in the code should help with prioritization.

Let me know if there’s anything else.