Voice updates from parallel agents overlap and interrupt each other

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

During a live voice call with the Agent, I often run parallel agent sessions (subagents, multitask, multiple Agent tiles). When more than one session produces a spoken status update around the same time, the TTS streams overlap—updates talk over each other instead of waiting for the current speech to finish.

Actual: Simultaneous updates interrupt and overlap, which makes hands-free supervision unusable when several agents report progress at once.

This is a prerequisite for any multi-voice / per-agent voice idea to work smoothly—you cannot tell who is speaking if multiple agents talk at once.

Steps to Reproduce

  1. Start a live voice call with the primary Agent.
  2. Kick off two or more parallel agents (subagents or separate tiles) that will speak progress via voice/TTS.
  3. Let both try to deliver spoken updates while you are still on the call.

Expected Behavior

While a voice session (or any active agent TTS playback) is in progress, additional spoken updates should be queued and played one after another when the current utterance ends (a single voice queue for agent TTS during live calls).

Operating System

MacOS

Version Information

Recent Cursor IDE on macOS (Oct 2026); exact build not captured at report time.

For AI issues: which model did you use?

Agent voice / live call (various models during parallel sessions)

Additional Information

Overlapping audio is worse than overlapping chat text (no skim/search). Related feature idea in Ideas: Multi-Agent Voice Routing — primary default voice and distinct per-child voices (forum topic 175813); that only helps if spoken updates do not overlap.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey, thanks for the detailed report.

During a single live voice call, voice updates should be queued. A call is tied to one chat, and messages should play one at a time, so a new one waits until the current one finishes. Results from subagents and background tasks come back through that same chat, so they go into the same queue too. Updates from other chats on that call should not be spoken at all.

Overlap can happen if two calls are running at the same time. You can start a separate voice call in each Cursor window, and calls in different windows play independently from each other. What you heard does sound like agents talking over each other.

For now, the best workaround is to keep only one call active:

  1. Before starting a call, check your other Cursor windows. If there is an active call there, end it.
  2. Start the call from the same chat where your parallel agents are running, like subagents or background tasks, so their updates come through that one call.

Can you confirm whether you had calls open in multiple windows when this happened? If the overlap happened with only one call active, please share about when it happened, including the date, time, and time zone, plus your exact Cursor version from Help > About, so we can investigate that specific call.

I do see a separate thread for the idea of giving different voices to agents: Multi-Agent Voice Routing: Primary Voice and Per-Child Agent Voices

We can keep that one as a feature request.

7

Hi Dean,

Can you confirm whether you had calls open in multiple windows when this happened?

Confirming the interruptions occurred with only one IDE window open.

If the overlap happened with only one call active

Correct - only one call active

about when it happened, including the date, time, and time zone

Around 1:30 PM +07:00 GMT

your exact Cursor version

Version: 3.26.16 (Universal)
VS Code Extension API: 1.128.0
Commit: 8fcb8ace5c73fa31f2e2707fd6783160e4ed3e40
Date: 2026-10-21T09:02:57.211Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.11.16
Chromium: 148.0.7778.280
Node.js: 24.19.0
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

I see I am due for an update, so I will implement - potentially solving.

In any event, the issue occurred multiple times through the day from between 11:30 AM - 04:00 PM ;; Would happen when I had multiple agents working on multiple tasks and the voice update would start skipping - getting interrupted - repeating speech, etc. To resolve I would simply limit my session to about 2 or 3 simultaneous tasks - then it was fine.

In any event - definitely loving interactive voice mode - it’s setting me free from hunching over my keyboard - truly lifestyle changing - 10x more productive - incredible!

I do see a separate thread for the idea of giving different voices to agents: Multi-Agent Voice Routing: Primary Voice and Per-Child Agent Voices

Yes, though as I thought about this more it seemed less realistic because the primary agent voice would often summarize multiple task updates in a single response - i .e., not really a clear path for multiple agent voices. Honestly, as soon as the multi-task interruptions are resolved I believe that’s the key - while the multiple agent voices would be good but only if tasks were more compartmentalized per agent, which has pros/cons - surely you understand.

In any event, thank you for the remarkable services.

Cheers,

NSDB

9

Thanks for the details, that really narrows it down. Since there was one window and one call, the idea of two parallel calls can be ruled out. From your description, the issue seems to happen within a single call when many tasks send updates at once: speech gets cut off, skipped, or repeated, while with 2 to 3 tasks everything works fine. That shouldn’t happen, and it isn’t related to your setup.

To find the right call, could you please confirm:

  1. The date and time zone. I want to make sure +07:00 is correct so I don’t mix anything up while searching.
  2. Whether the issue still happens after updating. If it does, next time it happens, please send the Request ID from the chat where the call was running right after it happens (chat menu in the top right > Copy Request ID), and about how many tasks were running in parallel at that time.

For now, your workaround of keeping no more than 2 to 3 tasks running at the same time during a call looks like the most reliable option.

And thanks for the kind words about voice mode. It’s great to hear that it really changes your workflow. I agree on multi-agent voices too. First we need to make sure updates from multiple tasks can be spoken without glitches, then we can think about different voices.

11

Hey, just a short follow-up to my previous reply. We were able to find the calls from that day based on the time and version, so there’s no need to send the time zone or Request ID.

It looks like this is what’s happening. When many tasks report back at the same time, the call speaks with almost no pauses. If the microphone picks up any sound during that time, the call may think you started talking. That could be your voice, background noise, or even the call’s own voice coming from the speakers. When that happens, the current update gets cut off mid-sentence so it can listen to you, and the part you didn’t hear is then repeated. That’s why you get missing parts, cut-offs, and repeats, and why things work fine with 2 to 3 tasks.

It’s still worth updating, but a single update probably won’t fully fix this. Besides limiting it to 2 to 3 tasks, these things may help:

  1. Use headphones during the call so the call audio doesn’t get picked up by the microphone.
  2. Mute the microphone in the call tray while you’re just listening to the stream of updates, then turn it back on when you want to say something.
  3. Ask the agent to give one combined update when several tasks finish, instead of a separate one for each task.

Were you using speakers or headphones when this happened? If you were already using headphones, or if the issue still happens with them, send us the approximate time it happened, with the time zone, and we’ll take a look at that call.

12

Were you using speakers or headphones when this happened?

open mic - not headphones - what you are saying makes sense - i’ll try to minimize background noise - thank you very much for your time and support.

14

Dean, just a quick follow-up thought… ideally would be nice if background noise was simply ignored and/or did not trigger a disruption of voice response. For example, would it be possible to distinguish between an intent to interrupt with actual speech vs. a simple “cough” ? I believe this would effectively solve any issues I was experiencing. Food for thought. Thanks again for your time and attention.

15

Update — Oct 23, 2026 (~1:15–1:20 PM Mazatlán / GMT-7)

Following up on @deanrie’s earlier notes on timing and audio pickup:

When: Approximately 1:15–1:20 PM Mazatlán time (GMT-7) on October 23, 2026.

What I heard: Voice responses were interrupted, repeated phrases, and sounded choppy / unclear—as if TTS kept restarting mid-sentence.

Environment: One live voice call in one Cursor window. The room was very quiet with little to no external audio.

Why external audio is unlikely here: With a quiet room and a single call, this still did not match “mic picked up background noise.” The audio bounced and jumped as if new spoken output was starting before the previous line finished.

More likely cause (rendering / voice layer): Response text landing while prior speech was still playing—the engine restarts on new/changed assistant output instead of queuing until the current utterance ends. That presents as overlap/repeat/choppiness even with one agent/call. This looks like a voice-output / update-coalescing issue, not microphone input.

Build (same day): Cursor 3.27.12 (Stable), macOS arm64 25.6.0.

Happy to capture a short recording or Request ID next time if useful.

16

Quick add-on to my note above (same ~1:15–1:20 PM Mazatlán window):

The pattern was very specific — voice would start, then stop, then say something, then say it again (repeat the same line).

I was in a completely empty room, open mic, no loud sounds at all (not even coughing). So this really did not feel like ambient noise triggering the call.

It lined up with agent jobs returning and pushing new spoken updates while earlier output was still playing — i.e. interruptions from in-flight agent responses, not external audio.

18

Voice call crash — Oct 23, 2026 (~2:14 PM PDT)

Separate from my earlier ~1:15–1:20 PM choppy/overlap notes: the live voice chat session crashed around 2:14 PM Pacific (PDT) on October 23, 2026.

What happened: Mid-call on a single Cursor window (STRIPE workspace; agent was helping with remote deploy / after-changes script follow-up). The voice call dropped / ended abruptly — not just overlapping TTS, but the call itself failed.

Environment: macOS arm64 25.6.0, one IDE window, one active voice call.

Build at crash:

  • Version: 3.27.12 (Universal)
  • VS Code Extension API: 1.128.0
  • Commit: df132ffba90dfc15a12e6b8f020ba4e5d026c4b0
  • Date: 2026-10-23T02:27:47.076Z
  • Layout: IDE | Build: Stable | Release: Default
  • Electron 42.11.16 | Chromium 148.0.7778.280 | Node 24.19.0 | V8 14.8.178.38-electron.0 | xterm.js 6.1.0-beta.291

Chat transcript continued in the agent panel after the crash; I rejoined voice afterward. Happy to provide Request ID if needed.

— NSDB

20

Additional voice crash event — Oct 23, 2026

Follow-up to my Voice call crash (~2:14 PM PDT) note above (post #18).

When: 2:49 PM PDT (GMT-7 / America/Mazatlán) on Friday, October 23, 2026 — 9:49 PM UTC.

What happened: Live voice chat crashed again mid-session (STRIPE workspace; agent work in flight on Cedrux / KYCAML tasks). The call dropped abruptly — same class of failure as the ~2:14 PM crash, not just choppy overlap from earlier in the day.

Environment: macOS arm64, one Cursor IDE window, one active voice call.

Build (same session family as prior report): Cursor 3.27.12 (Universal), VS Code Extension API 1.128.0, commit df132ffba90dfc15a12e6b8f020ba4e5d026c4b0, Stable / Default track.

Happy to add Request ID / logs if useful.

22

Update — Oct 23, 2026 (~5:05 PM GMT-7)

Happened again. During a single live voice call, the voice failed to complete sentences, repeated itself, and interrupted itself. There was no background noise at all. No other jobs were running.

— NSDB

23

Update — Oct 23, 2026 (~5:08 PM GMT-7)

Happened again, right now while this reply was being spoken. Same pattern: voice failed to complete sentences, repeated itself, interrupted itself. No background noise. No other jobs running.

— NSDB

25

Thanks for the detailed updates. We found the call around 5:05 PM. It was a single call in one window, with no connection drops.

A new message from the agent does not restart the phrase by itself. The voice cuts off mid-sentence only when the call decides that you started speaking. Then the current update gets interrupted, the call responds to what it thinks it heard, and after that it plays the interrupted update again from the start. That’s where the pattern comes from: it starts, stops, says something, then repeats the same phrase.

Even without other tasks, the chat attached to the call kept running and sent results into the call around 5:04 PM and 5:07 PM. So updates were coming through at that time. With an open mic and no headphones, the most likely trigger is the call’s own voice coming from the Mac speakers and getting picked up by the microphone again. Silence in the room doesn’t really prevent that. The second possible cause is that the voice service is treating a quiet background sound as the start of speech.

For now, this should help:

  1. Use headphones or earbuds. This is also the best test, since the call’s voice won’t get back into the microphone.
  2. If you stay on speakers, mute the microphone in the call tray while you’re just listening, then unmute when you want to say something.
  3. You can also lower the speaker volume.

The idea from #14 about telling coughs and accidental sounds apart from real speech makes sense. I passed it on to the team.

You moved the call drops into a separate thread: Crash voice chat. We’ll reply there so we don’t mix topics.

Could you try one session with headphones and let us know if the cutoffs and repeats go away? If it still repeats even with headphones, a short screen recording with audio and the approximate time with timezone would help a lot.