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
Found 3 possible duplicate issues:
- https://github.com/anthropics/claude-code/issues/3978
- https://github.com/anthropics/claude-code/issues/5099
- https://github.com/anthropics/claude-code/issues/2685
This issue will be automatically closed as a duplicate in 3 days.
- If your issue is a duplicate, please close it and 👍 the existing issue instead
- To prevent auto-closure, add a comment or 👎 this comment
🤖 Generated with Claude Code
Not sure which github issue the bot wants us to use, but this has become a must have feature for me. When announced, I was very excited for Agent support and I think it has a ton of potential. Unfortunately, I've completely stopped using it because of the lack of transparency. Without the ability to see what the agents are doing, they can't be used for non-trivial tasks.
definitely needs this, as nopoint of wasting tokens when you dont even know what kind of decisions CC is taking , are they correct or not etc etc
Also, for now, it's too much of a trouble to force Claude Code to actually use the sub-agents automatically on every suitable case. Together with lack of transparency, it makes sub-agents unfortunately unreliable for me (hope for improvements, because it's an essential thing).
Oh, does nobody know about the --verbose --debug option? That works okayish for me.
I was actually looking to see if anybody had opened the reason why it's only okayish: even though you can see the steps it's taking, it has an abysmal UI while at work... the subagent output plays VERY un-nicely with the rest of the TUI, and it causes the TUI to rapidly scroll around several times per second. It's basically an epilepsy test. I haven't gotten yet to the point in my claude code reversing sideproject to figure out where exactly the bug/problem is in their react usage, but I bet it's something simple like two hooks fighting eachother. There's also no way to see the thinking tokens, but that's less annoying than a terminal that's flying around like skynet has taken over.
is this supported? skills are also released. We need this as without this no-one can truly understand what the agent is doing and we on the other side can't optimize the prompt further
Yeah the only way is to make it log all messages with debug/verbose and create a tool that parses those JSONs and stores in a local DB, then create a local react frontend to display the sessions and tool calls ,subagent calls etc
Essentially you need to make a full stack of monitoring before you can troubleshoot subagents
It would be especially valuable to see which skills are being invoked by subagents. Maybe we can start with adding better visibility for skills in particular?
The Plan subagent often chains multiple skills together with zero indication to the user. When debugging or understanding what's happening, it would be super helpful to know that "Plan invoked the typescript skill, which then called Read/Edit tools".
It would be especially valuable to see which skills are being invoked by subagents. Maybe we can start with adding better visibility for skills in particular?
The
Plansubagent often chains multiple skills together with zero indication to the user. When debugging or understanding what's happening, it would be super helpful to know that "Plan invoked thetypescriptskill, which then called Read/Edit tools".
I'm also noticing that the latest update doesn't seem to be showing what skills are loading at all??
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.