Agents Window voice input records silence over RDP while Editor Window works

Support Bug Reports
, ,
1

Describe the Bug

Cursor version: 3.16.17 (Windows x64, user setup)
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0 (2026-08-14)
Plan: Pro
Layout: glass (Agents Window) = BROKEN, IDE/Editor Window = WORKS
Environment: Remote Desktop session (rdp-tcp), default input device “Удаленное аудио” (Remote Audio), volume 100%

WHAT HAPPENS
In the Agents Window, pressing the mic button / Ctrl+M starts recording, but the waveform stays a flat line and no text is inserted. In the logs, StreamStt connects to api2.cursor.sh and then TranscribeAudio fails with ERROR_PROVIDER_ERROR, provider HTTP 400 — the uploaded blob is empty/silent. Audio chunks reaching the server are 5-17 bytes.

In the Editor/IDE Window on the SAME machine, in the SAME RDP session, with the SAME microphone, voice input works perfectly and transcribes Russian speech live.

WHAT WE VERIFIED LOCALLY (measured, not guessed)

  1. Windows/WASAPI: Remote Audio is the default capture device for all three roles and delivers real speech (peak ~0.166, RMS about -31 dBFS vs -50 dBFS silence).
  2. Chromium (Edge 151) getUserMedia on the same device: audio arrives, peak ~0.0146.
  3. MediaRecorder audio/webm;codecs=opus on the same device: recorded blob decodes to real audio, peak ~0.42, 5.88 s.
  4. Cursor’s own renderer (Electron 40.10.3 / Chromium 144) getUserMedia: audio arrives, peak ~0.353, permission granted, all three audio inputs enumerated.
  5. Microsoft Store ChatGPT/Codex on the same PC hears this microphone with a live waveform.
  6. Windows microphone privacy is ON for desktop apps; Cursor is listed as having accessed the mic.

So the microphone, RDP redirection, WASAPI, Chromium, Electron and MediaRecorder are all healthy. Only the Agents Window voice path produces silence.

RELEVANT CODE DIFFERENCE
Agents Window uses batch recording (MediaRecorder → transcribeAudio). The Editor uses streaming STT (AudioWorklet → StreamStt). Only the batch path fails here.
Also note: out/vs/workbench/contrib/composer/browser/voice/voice-processor.js is absent from this build, and the whole voice/ folder does not exist. Your team called this a red herring earlier, but it is worth re-checking for this build.

WHY THIS IS URGENT
Voice input is a paid feature and it is unusable in the default window for anyone working over Remote Desktop. Many people work on remote/office machines this way. From the outside it looks like a broken microphone, so users spend hours on Windows settings, drivers and reinstalls before discovering that only one Cursor window is affected. Please prioritise this.

REPRO

  1. Connect to a Windows machine over RDP, leave the default input device as Remote Audio.
  2. Open the Agents Window, press the mic, speak 5-12 seconds, stop. Flat waveform, no text, provider 400.
  3. Ctrl+Shift+N to open the Editor Window, press the mic there, speak. Live transcription works.

Example stream: streamId d1e768db-c4bc-41ea-b57d-87bc2491c5b1, 2026-08-19 02:10 local (UTC+3), host api2.cursor.sh, requestId reported as “not-found”.

Steps to Reproduce

  1. Connect to a Windows machine over Remote Desktop (rdp-tcp). Leave the default input device as “Remote Audio”. Confirm the mic works elsewhere (Windows dictation, any browser).
  2. Open the Agents Window (Glass layout). Press the mic button or Ctrl+M and speak for 5-12 seconds, then stop.
  3. Result: the waveform stays a flat line, no text is inserted. Logs show StreamStt connecting to api2.cursor.sh and TranscribeAudio failing with ERROR_PROVIDER_ERROR / provider HTTP 400. Uploaded audio chunks are 5-17 bytes.
  4. Press Ctrl+Shift+N to open the Editor/IDE Window on the same machine, in the same RDP session, with the same microphone. Press the mic there and speak the same way.
  5. Result: live transcription works correctly and inserts Russian text.

Expected: voice input in the Agents Window transcribes speech, the same way the Editor Window does.
Actual: the Agents Window uploads silence and the request fails with HTTP 400.

Operating System

Windows 10/11

Version Information

Cursor IDE 3.16.17 (Windows x64, user setup), commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0, VSCode 1.99.3, Electron 40.10.3, Chromium 144.0.7559.226, OS: Windows 11 x64 build 26100 (Remote Desktop session)

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. We rarely get measurements at this level, and it really helps.

For now, here’s a workaround. Over RDP, use dictation in the Editor/IDE window Ctrl+Shift+N, not in the Agents window. You already noticed this. The streaming path in the Editor correctly captures and transcribes speech via Remote Audio, while the batch path in the Agents window returns silence in this environment. Until this is fixed, the Editor window is the working option for voice over Remote Desktop.

About the issue itself. What you’re seeing is not intended behavior, and it’s not something in your setup. Your mic, WASAPI, RDP redirect, and Electron clearly work fine. I’ve shared your details and repro steps with the team, and we’re tracking it. The missing voice-processor.js isn’t relevant here. That file is for the streaming path, the batch path doesn’t use it, so it doesn’t affect your case.

I can’t share an ETA yet, but I’ll post in the thread when there’s an update. If voice in the Editor window over RDP also starts acting weird, let me know.

7

Thank you for the quick and clear answer, and for passing it to the team.

Confirming the workaround works: over RDP, dictation in the Editor/IDE window (Ctrl+Shift+N) has been stable for me, transcribing Russian correctly with the same Remote Audio device. I will use that until the Agents window is fixed, and I will report back here if the Editor path ever starts misbehaving too.

Good to know voice-processor.js is a dead end for this case, thanks for clearing that up. For the record, my install is stock: I had experimented locally while debugging, but everything was reverted and the app is unmodified.

If it helps, I am happy to run any test build or extra diagnostics on this machine, since it reproduces the issue every time. Just tell me what data you need.

8

Thanks for confirming the workaround and for being willing to help. That’s genuinely useful, especially since the repro is consistent.

One thing that would really help the team: you currently have Privacy Mode enabled, so your requests reach the server anonymized and we can’t find the specific streamId in the logs. If you’re OK with it, please do this:

  1. Temporarily turn off Privacy Mode: Cursor Settings > Privacy.
  2. Reproduce the issue in the Agents Window (mic or Ctrl+M, 5 to 12 seconds of speech).
  3. Right after that, grab the Request ID: chat menu (three dots in the top right) > Copy Request ID.
  4. Send that Request ID here, along with the approximate time of the attempt and your timezone.

With the linked Request ID, we’ll be able to pull up your exact attempt in the logs and match it with what we’re already seeing. You can turn Privacy Mode back on right after.

I won’t ask for any separate test builds for now. If the team needs you to run anything, I’ll reply here. I can’t share an ETA yet, but I’ll post an update on the issue in this thread.