Skip to content

[Bug]: Spawned subagent rows aren't clickable — can't drill into a subagent's work #8137

Description

@Ygilany

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. In a thread, prompt the agent to spawn a subagent (e.g. via the Task/Agent tool).
  2. Wait for it to complete; a "Ran N subagent(s)" Work Log entry appears with a "View ▸" link.
  3. Click "View ▸" — it opens the right-side Agents panel.
  4. Under "Direct spawns" (or inside a workflow's phase list), click directly on the row for the subagent you just spawned.

Expected behavior

Clicking "View ▸" jumps to (or highlights) the specific subagent that was just spawned. Clicking an individual row surfaces more detail about what that subagent actually did.

Actual behavior

"View ▸" only opens the Agents tab in general — it doesn't select or scroll to the specific subagent (MessagesTimeline.tsx's AgentSpawnCtaRow → ChatView.tsx just calls useRightPanelStore.open(thread, "agents")). Each row under "Direct spawns" (AgentsPanel.tsx, AgentRow) renders as a plain <div> with no onClick, no button semantics, and no pointer cursor — clicking it does nothing.

Two signals suggest this is unfinished work rather than deliberate design:

  • RuntimeSubagent.runHandles (packages/client-runtime/src/state/subagentRuntime.ts) carries transcriptDir and sessionUrl per subagent, but nothing in the UI reads either field — and server-side, these are only ever populated for the Workflow tool's result (ClaudeAdapter.ts, gated on tool.toolName.toLowerCase() === "workflow"). A plain Task-spawned subagent (e.g. Explore) never gets a transcript link at all.
  • Each RuntimeSubagent also tracks a recentActivity ring buffer (up to 6 timestamped tool/progress summaries, fully computed and unit-tested in subagentRuntime.ts/.test.ts), but it's never rendered anywhere. Worse, the fold that builds it only reads task.started/progress/updated/completed and a bare tool.progress heartbeat (tool name + elapsed seconds only) — it ignores the richer item.started/item.updated events already flowing through the same stream, which carry the actual tool input/command text and result and are already attributable to the right subagent. So even once rendered, the activity trail is closer to "▸ Bash" than to anything showing real work.

Impact

Minor bug or occasional failure

Version or commit

main @ 9996038

Environment

Not applicable — this is a code-review finding surfaced while working in the repo, not an issue hit during a live user session.

Logs or stack traces

None — this is a missing UI affordance and a data-fold gap, not a crash.

Workaround

None currently. There's no way to see more than a single truncated status line for a subagent from the UI today.


Note: filed by hand (not via npx t3 triage, which is an interactive user-facing flow); I don't have label-write permission on this repo from my fork, so bug/needs-triage haven't been applied — please add them if this is confirmed.

Activity

  1. changed the title [-]Spawned subagent rows aren't clickable — can't drill into a subagent's work[/-] [+][Bug]: Spawned subagent rows aren't clickable — can't drill into a subagent's work[/+] on Aug 24, 2026
  2. Ygilany commented on Aug 24, 2026

    @Ygilany
    Author

    Correction to the original report, based on inspecting real persisted activity data (not just source): the suggested "smallest fix" of folding item.started/item.updated into recentActivity for richer per-tool detail does not work for standalone Task-spawned subagents (Explore, general-purpose, etc.).

    Verified against a real state.sqlite:

    • item.started/item.updated never appear in persisted projection_thread_activities rows — the runtime event kind gets renamed to tool.started/tool.updated/tool.completed before persistence.
    • More importantly, genuine inner tool calls (Bash, Read, etc.) made inside a standalone subagent never carry an agentId back to the parent thread's activity log (0 real matches across thousands of rows in a large dev database). The only rows that legitimately carry agentId are collab_agent_tool_call — the spawn call itself, tagged with the newly-created agent's ID, which is a different relationship (linking the spawn action to its result) than "this Bash call belongs to that subagent."
    • Standalone subagents run as fully separate provider sessions; their internal tool calls are simply never surfaced to the parent thread's stream. Only the coarse task.progress/tool.progress heartbeats are, and in a real dev database only 9 of 186 task.progress rows ever carried a human-readable summary — the rest are bare tool names (lastToolName only).

    So the recentActivity ring buffer genuinely has nothing richer to show for the common case today; the original finding about it being unrendered still stands, but "wire in item.started" is not a valid fix. Actually reaching per-tool-call detail for standalone subagents would need new server-side plumbing (their own transcript is not currently linked to the parent thread at all — see the transcriptDir/sessionUrl note above, which is Workflow-only).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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