Feature Request: UI for Subagent Execution Transparency and Debugging
Title: Feature Request: UI for Subagent Execution Transparency and Debugging
Is this a feature request or a bug report?
Feature Request
Problem Description
Currently, when a task is delegated to a subagent (either automatically or by explicit user request), its execution process is a "black box." The user sees that a subagent task has started and, after some time, receives the final output or result.
There is no built-in, user-friendly way to view the subagent's internal "thinking" process, the specific tool calls it makes, the outputs of those tools, or any errors it might have encountered along the way.
This lack of visibility makes it:
- Difficult to debug: If a subagent fails or produces an unexpected result, it's nearly impossible to trace its steps to understand what went wrong.
- Hard to trust: Users cannot verify that the subagent is taking a sensible or efficient path to solve the problem.
- A missed learning opportunity: Users can't learn from the subagent's successful or unsuccessful strategies to improve their own prompts or subagent definitions.
Proposed Solution
I propose adding an expandable UI element in the main conversation transcript for each subagent task. By default, this element would show a summary (e.g., "Debugger subagent is working on the task..."). When clicked, it would expand to reveal the subagent's complete, isolated transcript.
This nested transcript should display the full lifecycle of the subagent's execution, including:
- The subagent's
thinkingblocks. - Each
Tool Callit makes (e.g.,Bash,Read,Edit), including the parameters. - The corresponding
Tool Outputfor each call (e.g., stdout/stderr, file content). - The final result passed back to the main agent.
Mockup / Visual Idea
Here is a simple text-based mockup of how this could look in the terminal:
Collapsed View (Default):
> Use the debugger subagent to fix the error in user.ts
┌─ Task: Debugging error in user.ts [Running...] ───────────┐
│ ► debugger subagent is working on the task. (Click to expand) │
└───────────────────────────────────────────────────────────┘
Expanded View (After User Interaction):
> Use the debugger subagent to fix the error in user.ts
┌─ Task: Debugging error in user.ts [Completed] ────────────┐
│ ▼ debugger subagent transcript: │
│ │
│ <thinking> │
│ Okay, I need to investigate the error in `user.ts`. │
│ First, I'll read the file to see the relevant code. │
│ </thinking> │
│ │
│ [Tool Call: Read] │
│ - file_path: user.ts │
│ │
│ [Tool Output] │
│ - <content of user.ts is displayed here> │
│ │
│ <thinking> │
│ I see the potential null reference on line 42. I will │
│ add a null check before accessing the property. │
│ </thinking> │
│ │
│ [Tool Call: Edit] │
│ - file_path: user.ts │
│ - edits: ... │
│ │
│ [Tool Output] │
│ - Success │
└───────────────────────────────────────────────────────────┘
Benefits
- Improved Debugging: Users can immediately see why a subagent failed or went off-track.
- Increased Transparency & Trust: Users can see exactly how the subagent is working, building confidence in the tool.
- Better User Feedback: If a subagent is stuck in a loop or using the wrong tool, the user can see this and interrupt with better instructions.
- Educational: It provides an excellent way to understand the agentic capabilities of Claude Code and learn how to build more effective custom subagents.
Current Workarounds
The current methods for gaining this visibility are not ideal for a typical user workflow:
claude --verbose: While this provides the raw data, it floods the main terminal view, making it difficult to follow the high-level conversation. It's an all-or-nothing firehose of information.- Custom Hooks: Setting up
PreToolUse/PostToolUsehooks to log all tool calls to a separate file requires extra setup, scripting, and monitoring an external log file, which is a cumbersome experience compared to an integrated UI.
This feature would be a significant quality-of-life improvement and would make the powerful subagents feature much more accessible and useful. Thank you for considering it
This issue has 12 comments on GitHub. Read the full discussion on GitHub ↗