This issue has already been reported in several forum posts, all closed 22 days after the last reply, without any real solution:
To summarize, when typing, if you move the cursor position and then try to shift-enter or paste text, the text may be inserted at the cursor’s previous position. This happens intermittently, and seems to happen the longer the chat is open. A workaround I’ve noticed is that if, after you move the cursor to your desired position, if you type any character and delete it, then when you shift-enter or paste text, it will be inserted in the desired spot (i.e. normal typing actually changes the position of the cursor, while shift-enter or paste does not). Also, closing and re-opening the chat or restarting cursor entirely resets the issue, but it can intermittently happen later on again.
I’ve noticed similar behavior with the Voice Input. You start by using Voice Input to enter some initial text. Then you stop the voice input to either correct an error, enter context files, paste text, or enter ordinary text manually. You move the cursor to a different position than where the Voice Input ended at. You use the keyboard shortcut (default: Ctrl + Shift + Space) to start Voice Input again. Once you start saying something new, the text will be entered wherever the Voice Input previously ended instead of at the Cursor’s current location. Unlike the other examples of this issue which are intermittent, I was able to reproduce this version of the issue every time I tried.
Steps to Reproduce
The issue is mostly intermittent, happening after the chat / cursor has been open a long time, possibly accelerated by having chat open as editor or in a separate window. The issue involving Voice Input can be reproduced (see steps above).
Expected Behavior
Text is always entered at the current location of the cursor (insertion point).
Hey, thanks for the report. I see you’ve gathered all the previous threads - this is indeed a known issue.
Regarding “the team is working on a fix” from my last response - I have to admit that was an over-promise on my part. The bug is logged, but I can’t provide a timeline for when it will be fixed.
The workarounds you found are correct:
Reopen chat / restart Cursor
Type a character + delete before Shift+Enter/paste
About the voice input issue - that’s particularly interesting since it reproduces consistently. Can you help with debugging:
When you reproduce the voice input issue - open Help > Toggle Developer Tools > Console tab. Are there any errors or warnings there? Please share them here.
One more question: does the voice input problem occur right away on the first use in a new chat, or does it also build up over time like the main bug?
Your report helps increase the visibility of the issue - I’ll add it to the existing tickets.
There are quite a few errors when I first open the developer tools. Let me know if you need those. After that, there are no errors when I start the Voice Input and during the voice input entry. When I stop the first voice input entry, there is the following:
workbench.desktop.main.js:34239 [Deprecation] The ScriptProcessorNode is deprecated. Use AudioWorkletNode instead. (https://bit.ly/audio-worklet)
initAudioContext @ workbench.desktop.main.js:34239
await in initAudioContext
start @ workbench.desktop.main.js:34239
await in start
run @ workbench.desktop.main.js:33426
handler @ workbench.desktop.main.js:57
invokeFunction @ workbench.desktop.main.js:34462
(anonymous) @ workbench.desktop.main.js:33959
$Do @ workbench.desktop.main.js:55
_me @ workbench.desktop.main.js:55
_tryExecuteCommand @ workbench.desktop.main.js:33959
executeCommandImpl @ workbench.desktop.main.js:33959
executeCommand @ workbench.desktop.main.js:33959
_doDispatch @ workbench.desktop.main.js:33942
_dispatch @ workbench.desktop.main.js:33942
(anonymous) @ workbench.desktop.main.js:33943
workbench.desktop.main.js:34037 [transport] Stream error reported from extension host ConnectError: [internal] User requested cancellation of ai connect transport stream 88822e41-69b3-4987-b0f8-1b70e302e501
at uKd.$endAiConnectTransportReportError (workbench.desktop.main.js:11431:32845)
at w0t._doInvokeHandler (workbench.desktop.main.js:33978:23171)
at w0t._invokeHandler (workbench.desktop.main.js:33978:22913)
at w0t._receiveRequest (workbench.desktop.main.js:33978:21545)
at w0t._receiveOneMessage (workbench.desktop.main.js:33978:20362)
at lin.value (workbench.desktop.main.js:33978:18389)
at Oe._deliver (workbench.desktop.main.js:49:2962)
at Oe.fire (workbench.desktop.main.js:49:3283)
at R3t.fire (workbench.desktop.main.js:11415:12156)
at MessagePort.<anonymous> (workbench.desktop.main.js:36039:18408) {arch: 'x64', platform: 'win32', channel: 'stable', client_version: '2.4.21', error: {…}, …}
error @ workbench.desktop.main.js:34037
$endAiConnectTransportReportError @ workbench.desktop.main.js:11431
_doInvokeHandler @ workbench.desktop.main.js:33978
_invokeHandler @ workbench.desktop.main.js:33978
_receiveRequest @ workbench.desktop.main.js:33978
_receiveOneMessage @ workbench.desktop.main.js:33978
(anonymous) @ workbench.desktop.main.js:33978
_deliver @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:11415
(anonymous) @ workbench.desktop.main.js:36039
After that I can manually enter text and then restart the voice input. There are no more errors until I end the voice input again, and I get similar errors to the ones I previously got, except there’s a different transport stream identifier: 1fdcea6c-bf54-481f-b401-3f4a0f16d7cf.
Here’s an the example text I was able to produce:
Yes it consistently occurs right away in the first chat after restarting Cursor.