Skip to content

[Feature]: Cursor provider subagent support in the Agents panel (and parent wake on completion) #6644

Description

@mictonycug

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

When using the Cursor provider (cursor-agent / ACP), native Cursor subagents / Task children are effectively invisible and hard to supervise in T3 Code:

  1. They do not appear in the Agents panel (roster stays empty / “No agents yet”), so there is no way to track status, progress, model, tokens, or completion the way Claude Task and Codex collab children do after feat: native subagent & workflow observability #5219.
  2. Bug-shaped symptom (even more painful): when those children finish, the parent/spawner does not wake (resume) correctly. The parent turn can settle or look finished while delegated Cursor child work is still the logical next step, and child completion does not reliably bring the spawner back. The overall multi-agent run then stalls unless the user manually nudges the parent.

Net: Cursor fleets are both unobservable and unreliable to complete, which makes parallel Task/subagent workflows on Cursor much worse than on Claude/Codex.

Proposed solution

Bring Cursor to the same subagent observability + lifecycle parity Claude/Codex already have:

  1. Map Cursor-native subagent / Task child lifecycle onto the existing persisted task.started / task.progress / task.updated / task.completed activity stream (with TaskAgentLinkage), so the Agents panel can show live roster rows.
  2. Keep child-internal narration/tools out of the parent transcript (quiet timeline / Agents panel), matching feat: native subagent & workflow observability #5219 behavior.
  3. Fix the completion path so child terminal states wake / resume the parent spawner (or keep correct backgroundLiveness until the overall run settles), instead of leaving the thread looking done while the logical fleet is incomplete.

No nested-thread UX required for a first pass (#538 can stay separate).

Why this matters

Cursor is a first-class provider, and native subagent / Task fan-out is a normal Cursor workflow. Without Agents-panel membership and parent wake-on-completion, users cannot supervise fleets or trust that delegated work will finish the parent turn. That forces manual babysitting and burns the value of parallel agents.

Smallest useful scope

Cursor adapter only:

Alternatives considered

Risks or tradeoffs

Examples or references

Observed on this environment while using Cursor threads that spawn subagents (including threads titled along the lines of “Spawn Subagents for Testing” / “Spawn Agents During Testing”):

  • T3 Code: 0.0.34-nightly.20260813.1085 (systemd user service / local server)
  • cursor-agent: 2026.08.11-e8db854 (~/.local/bin/cursor-agent, ACP mode)
  • OS: Ubuntu 24.04.4 LTS, Linux x86_64
  • Provider: Cursor (providerInstances.cursor, binary cursor-agent)
  • Typical thread config: runtime_mode: full-access, model selection { instanceId: "cursor", model: "default" }
  • Surface: web/desktop Agents panel for Cursor provider threads

Likely cause / prior art: #5219 populated Agents from task.* for Claude + Codex only. task.started emission appears in those adapters today; Cursor ACP paths do not appear to project child-agent lifecycle onto task.*, which would explain both the empty Agents roster and broken parent wake / background-liveness for Cursor fleets. Same adapter-parity class as #5952 / #6468.

Closure signal: a Cursor thread that spawns ≥1 native subagent should (a) show stable Agents-panel rows through running → terminal states, and (b) resume the parent / keep correct liveness when children complete without a manual nudge.

Contribution

  • I would be open to helping implement this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions