CLI Tasks pager keeps zombie Subagent call-add entries on Grok 4.6

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Follow-up to the closed thread CLI: GPT-5.6 Sol starts tons of tasks, and they never finish (auto-closed after 30 days; cannot reply there).

Dean’s diagnosis still matches: leftover Subagent call_… placeholder lines in the Tasks pager after the workers have finished. Two additions:

  1. Not Sol-only. Reproduced on Cursor Grok 4.6 High Fast.
  2. Resuming a finished subagent with a STOP prompt does not clear the chip. It adds another running line (Tasks (2) → Tasks (3)).

Details:

  • Parent launched Task subagents (generalPurpose / bugbot) in a long --yolo session.
  • Subagent jsonl already has turn_ended: success.
  • ps shows only the parent cursor-agent — no extra worker processes.
  • Pager still showed Subagent call-add as running for 45+ minutes.
  • k / /clear do not remove the lines (same as Dean said). Only restarting the CLI session clears them.

Steps to Reproduce

  1. Long CLI --yolo session, model Grok 4.6 High Fast, CLI 2026.09.18-9a7762b, macOS arm64, Orca/zsh.
  2. Parent uses the Task tool (generalPurpose / bugbot), including after context compact.
  3. Subagent transcripts end with turn_ended: success.
  4. Open the Tasks pager: leftover Subagent call-add rows still say running.
  5. Resume a completed subagent with a stop prompt: count increases instead of clearing.

Expected Behavior

Finished / missing workers leave the Tasks list. Resume of a completed agent must not create a new running placeholder. k / /clear (or Stop) should dismiss zombie rows.

Operating System

MacOS (darwin arm64)

Version Information

CLI Version 2026.09.18-9a7762b (current)
Model Cursor Grok 4.6 High Fast
Subscription Tier Pro+
OS darwin (arm64)
Terminal orca
Shell zsh
Session 5ef6f8e1-8842-4522-8496-2c1f1305c8ca

For AI issues: which model did you use?

Cursor Grok 4.6 High Fast

Does this stop you from using Cursor

Sometimes — the pager is wrong; only workaround is restart the CLI session.

9

Hey @vzts, thanks for the detailed write-up. Good news: your subagents did finish - every Task in that session completed on our side, matching the turn_ended: success you saw. The Subagent call-add rows are leftover placeholders in the Tasks list, not running work.

You also nailed a second cause: resuming a recently-finished subagent adds a new row instead of clearing it, so the count climbs. A stop prompt won’t help there.

This isn’t intended behavior and isn’t anything on your end - it’s an issue we’re tracking. For now the only way to clear the rows is to restart the CLI session; k, /clear, and Stop won’t remove them.