On Linux with IBus, Pinyin and English input work normally both inside and outside Cursor.
Wubi also works in other applications (including browsers), but in Cursor’s chat input it intermittently fails to commit text.
Symptoms: Wubi candidates appear and can be selected, but the committed character does not appear in the chat textbox. Switching input methods or refocusing the input sometimes restores normal behavior.
Steps to Reproduce
Open Cursor and focus the chat input box.
Switch to ibus-table-wubi.
Type and commit several Chinese characters via candidate selection.
Intermittently, candidates are shown but committed text is not inserted into the chat input.
Switch to ibus-sunpinyin or English input, and input works normally; switching back to Wubi may recover.
Actual Result
Wubi intermittently fails to insert committed text in Cursor chat input.
In the same input field and session, Pinyin and English continue to work normally.
Expected Result
Wubi should reliably commit text to Cursor chat input, same as Pinyin and English.
Scope / Comparison
The issue is observed only in Cursor chat input.
Wubi works normally in other applications (including browsers).
Pinyin and English work normally across all tested applications.
Temporary Workarounds (not a root fix)
Switch away from Wubi and switch back.
Blur and refocus the chat input box.
Sometimes input recovers after these actions.
Hey, thanks for the detailed report. A direct ibus-table vs ibus-sunpinyin comparison in the same session is a really useful signal.
This matches a known issue on our side with Linux IME and chat input. We’re tracking it, and I added your Wubi case as another data point. I can’t share an exact fix timeline yet, but I’ll post in the thread once there’s an update.
A couple quick questions that could help:
Does it reproduce every time in a fresh chat, or only after certain actions, like an inline edit or switching panels?
If you run Cursor on Wayland, does the same behavior happen, or is it only on X11? You can check your current session with echo $XDG_SESSION_TYPE.
For now, the workaround is what you already found: blur and refocus the input, or switch the IME.
In the current Cursor version (3.3.30), the aforementioned Wubi input issue occasionally occurs right after launching the app. However, if I switch to another input method or maybe restart the app, the issue rarely resurfaces once Wubi starts working correctly for the first time.
The issue occurs under X11, I am not using Wayland.
In the previous Cursor older version (I don’t recall the specific version number, but it was downloaded about 1–3 months ago), Wubi input was consistently broken. I performed a fresh install of 3.3.30 a few days ago after uninstalling the old version, and the failure rate is now much lower.
My system environment and input method settings have remained unchanged throughout this update.
The crash mostly happens right after launch. After the first IME switch or a restart, the issue goes away.
In 3.3.30 the crash rate is noticeably lower than in an older version from 1 to 3 months ago.
The drop in failure rate between versions suggests part of the fix already landed, but there’s still an edge case with Wubi right after launch. I can’t share an exact ETA yet. As soon as we have an update on the fix, we’ll reply in the thread.
If you notice the crash becomes reproducible after a specific action, like opening or closing a panel, inline edit, or resizing the window, let us know. That’ll help us narrow it down.