One Task spawn shows two identical Working subagents (`::` + Thinking / Starting up) while parent card is Stopped

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In a local Agent chat, the parent issued one Task tool call (subagent_type=cavecrew-reviewer, description Review prefix reclaim diff).

The parent turn then showed:

  • A subagent row Review prefix reclai… marked Stopped
  • Edit attempted
  • Waiting for subagent

At the same time the bottom Working tray listed two rows with the same name:

  • :: Review prefix reclaim diffThinking
  • :: Review prefix reclaim diffStarting up

I did not click Stop, retry, or send another message to “wake” it. The duplicate appeared on the first spawn.

This looks related to, but not the same as, Subagent is stuck immediately in Stopped state. Staff there said the Stopped label is often a display issue, and that interrupting can spawn a second subagent. Here the second row appeared without an interrupt, and the Working tray used a :: prefix I did not type.

Steps to Reproduce

  1. Local Agent Mode chat (not Cloud Agents). Model: Cursor Grok 4.6.
  2. Long implementation turn; parent calls Task once to review the uncommitted diff (cavecrew-reviewer, description Review prefix reclaim diff).
  3. Do not click the subagent card, Stop All, or re-prompt.
  4. Watch the parent card vs the Working tray.

Expected Behavior

One Task call → one subagent. Parent card and Working tray should show the same single job. Status should be Starting up / Thinking / running, not Stopped plus two live clones.

Actual Behavior

  • Parent card: Stopped + Waiting for subagent
  • Working tray: two identical :: Review prefix reclaim diff rows (Thinking + Starting up)
  • Tray has Stop All

I do not know if both rows billed/ran, or if one was a ghost. The named review did eventually return a result to the parent.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.18.9
VS Code Extension API: 1.128.0
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Date: 2026-08-27T01:42:22.092Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 27.0.0

For AI issues: which model did you use?

Grok 4.6 xhigh fast

For AI issues: add Request ID with privacy disabled

From local cursor.requestTraces.log / structured logs (implement turn that spawned the review):

  • Parent request: ff7bda32-66a3-4df6-85fd-a97de96ce86f
  • Parent retry after stall: e0fd1ca9-ec5b-4cca-90ed-4f91731e0a0a
  • Subagent stream request: 0b49fbc3-0eeb-476c-9220-478e1a12a21a
  • Parent composer: 65aaf86a-179b-4bbf-984d-8eb78089c2e5
  • Subagent composer: a5cc05ec-7ff5-408b-8164-856f29cc1af4

Additional Information

Cursor log excerpt — duplicate Working subagent UI
Session folder: ~/Library/Application Support/Cursor/logs/20260829T172232/window2_wb1
Times below: local = UTC+8; requestTraces uses UTC.

IDs

  • Parent composer: 65aaf86a-179b-4bbf-984d-8eb78089c2e5
  • Parent request (implement turn): ff7bda32-66a3-4df6-85fd-a97de96ce86f
  • Parent retry after stall: e0fd1ca9-ec5b-4cca-90ed-4f91731e0a0a
  • Subagent composer: a5cc05ec-7ff5-408b-8164-856f29cc1af4
  • Subagent stream request: 0b49fbc3-0eeb-476c-9220-478e1a12a21a
  • Subagent span: 639b0559b32169a3

— cursor.requestTraces.log (one subagent.request only) —

2026-08-29T13:34:16.116Z span_started name=“exec.handle” requestId=ff7bda32-66a3-4df6-85fd-a97de96ce86f
2026-08-29T13:34:16.280Z span_started name=“subagent.request” spanId=639b0559b32169a3 requestId=ff7bda32-66a3-4df6-85fd-a97de96ce86f
2026-08-29T13:34:16.281Z recoverConversationStateFromTranscript requestId=0b49fbc3-0eeb-476c-9220-478e1a12a21a composerId=a5cc05ec-7ff5-408b-8164-856f29cc1af4
2026-08-29T13:46:56.259Z span_completed name=“subagent.request” spanId=639b0559b32169a3 requestId=0b49fbc3-0eeb-476c-9220-478e1a12a21a composerId=a5cc05ec-7ff5-408b-8164-856f29cc1af4 durationMs=759979

No second span_started name=“subagent.request” in this parent turn after 13:34.

— renderer.log —

2026-08-29 21:05:41.682 [info] [ComposerWakelockManager] Acquired wakelock reason=“agent-loop” composerId=65aaf86a-179b-4bbf-984d-8eb78089c2e5
2026-08-29 21:34:16.330 [info] [buildRequestedModel] composerId=a5cc05ec-7ff5-408b-8164-856f29cc1af4 catalogModelId=grok-4.6
2026-08-29 21:49:54.294 [info] [ComposerWakelockManager] Released wakelock reason=“generation-ended” composerId=65aaf86a-179b-4bbf-984d-8eb78089c2e5

— Cursor Structured Logs (parent stall → retry; parent card likely showed Stopped) —

2026-08-29 21:05:41.607 agent.turn.start request_id=ff7bda32-66a3-4df6-85fd-a97de96ce86f conversation_id=65aaf86a-179b-4bbf-984d-8eb78089c2e5
2026-08-29 21:37:19.232 [NAL client stall detector] Stream stall detector disposed reqId=ff7bda32-66a3-4df6-85fd-a97de96ce86f stall.duration_ms=8904 stall.event_type=disposed
2026-08-29 21:37:19.233 [AGENT_ERROR_DIAGNOSTICS] requestId=ff7bda32-66a3-4df6-85fd-a97de96ce86f decision=RETRY errorName=ConnectError underlyingConnectError.codeName=Canceled
2026-08-29 21:37:21.295 [nal_agent_retries] Retrying attempt 1 requestId=e0fd1ca9-ec5b-4cca-90ed-4f91731e0a0a originalRequestId=ff7bda32-66a3-4df6-85fd-a97de96ce86f
2026-08-29 21:49:54.157 [nal_agent_retries] Request successful attempt=1
2026-08-29 21:49:54.290 Stream completed successfully requestId=ff7bda32-66a3-4df6-85fd-a97de96ce86f totalTimeMs=2652680.5

Screenshot of two Working rows was taken 2026-08-29 21:44 +08, while the single subagent.request was still running (until 21:46:56 +08).

This report was AI-generated.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Thanks for the report @JiangnanZhang! This looks similar to the issue already reported here.

The good news is that only one subagent actually ran, and only one was billed. We verified on our side, there is exactly one subagent request for that turn, so the second row was purely a display ghost doing no work and costing nothing. The real one is the row showing live progress.

This is a known issue we’re already tracking, and I’ve added your report to it!