Subagent workflows disappear from chat sometimes entirely. You become unable to access them whatsoever to see their progress. Agent tasks running under the Cursor host lose their task IDs from the shell and you cannot interrupt them. They do not appear in the agents/tasks sidebar anywhere either.
Steps to Reproduce
Well, just set up a long running or multi-agent parallel workflow and it’ll happen to you eventually it seems like. I do 10 agents at a time, which my machine handles fine. Running i914900k, 64gb ram, nothing super heavy on the workflows. I had to use Claude Opus 4.8 Max to catch it so it’d ask me a question. This has ate idk how much in my API costs recently, I rotate ultra accounts so I’m not super happy about it. Coming on here to request an urgent fix because it’s making my Cursor workflows 100% unusable.
Expected Behavior
They stay in chat, running, or at least accessible and don’t lose their task IDs from the cursor host and continue to run hidden in the background without anyway to check progress or fix them.
Thanks for the detailed reports! I looked into the backend logs for your requests and you’re hitting a known issue we’re already tracking on our side. It’s a server-side stream-ordering bug (the agent stream hits a gap it can’t recover from, so it sits in that “buffering” state until it times out), not anything wrong with your machine or setup.
When you mention running multiple agents, do you mean spinning up ~10 subagents within a single agent turn, or ~10 separate agent chats/conversations running at once?
I usually use a set up similar to this. Sort of went from me monitoring the main agent which handles specialist subagents, added the super agent to replace myself in the loop once the main/specialists were consistent with no issues.
super agent -----v
main agent 1 ——–v
subagent 1
subagent 2
etc. to subagent 10
main agent 2 ---v
repeat
So I’ll open a chat and tell it to run my workflow, it’ll spawn the initial subagent which has it’s directives, then that one creates main agents which spawn 10 at a time (number varies), once those 10 are done that main agent will shutdown, super opens a new main for the next portion of the workflow.
Let me know if I can provide anymore information. Sooner the better lol, I’m running this across 5 machines but it keeps bottle necking me and killing some api % off each time having to rework or get things back on track.
any ideas when we could be seeing an update to fix this? @Colin
Not trying to be a thorn, but its sort of killing keeping things more autonomous and adding a lot to my workload. Not to mention it’s killing my api costs.
Ah, I didn’t know that was in the guidelines. Will not do that going forward. I’ll try to find a workaround in the mean time or switch workflow somehow
