Repository navigation
Subagent support as nested threads #538
Description
Activity
Let me know if I could raise a PR for this.
Do you support
max_depthsettings, e.g. when subagents can spawn more subagents?BTW Would love this! ❤️
hey @BleedingDev , my workflow currently doesn't need more than 1 depth so didn't build for it. Can add it as a separate PR if this gets merged or if Theo or Julius build their solution, we can request them or submit a PR.
I can help as well. :) Thanks for clarification.
like this idea, i think it can be paired with #915 and add a nested "review" thread (either with a little review badge or tag)
Reacted by ratulsarnaThis would really improve the visibility into subagent activity.
Currently, OpenCode is the only thing that really does this well (easily navigating between different subagent threads)
But that is a CLII created this exact thing in my fork, still testing, will push soon.
Reacted by Jeroen EvensLinked fork is a bit outdated, so I forked my own behavior: Quicksaver/t3code@70028f8...baa23ab
Full implementation notes at https://github.com/Quicksaver/t3code/blob/main/SUBAGENTS.md
These changes exist in my multi-customizations fork, but I'm happy to create a branch just with these changes if wanted and open a PR for it. 👍
Summary of behavior changes
The feature is implemented for Codex only. Unsupported providers should continue using the previous inline subagent-output behavior until they expose durable child-thread lineage.
The current behavior is:
- A Codex subagent is represented as its own conversation thread.
- Active subagent threads appear in the sidebar nested under the direct parent that spawned them.
- Completed, errored, interrupted, or stopped subagent threads are normally hidden from the sidebar but remain reachable from the parent conversation view. When a terminal subagent conversation is the active route, that subagent and any intermediate subagent ancestors are shown in the sidebar at their normal nested positions until the user navigates away.
- A parent conversation view shows only parent-owned output and subagent summary blocks for direct children.
- A child conversation view shows only that child's output, tool calls, diffs, MCP calls, and other actions. Grandchildren appear only as blocks inside their direct parent child view.
- Users cannot prompt or steer a subagent. The child view exposes stop control only while the child is running and a header button for returning to its direct parent conversation.
- Stopping a parent does not automatically stop running children. Stopping a child explicitly targets that child.
- Archive/delete actions are exposed only for root parent conversations and should include descendant subagent threads as part of that root lifecycle.
Video example
In this example you can see the above-described behavior in action. At around the 1:18 mark, one of the subagent's box was clicked and it took the screen to that subagent's conversation view. Then a few seconds later it clicks the "back arrow" next to the title to go back to the parent conversation's view.
subagents.mp4
Update looks from latest head:
#2829 will ahve this
Reacted by Luís Miguel, Rowan-Paul, Pratyush Poddar and Shubham PawarThanks for working on this. I searched the existing requests before posting and found this issue plus #3138, #4456, #5043, and #4962, so I’m adding feedback here instead of opening a duplicate.
From a user perspective, “sub-agent support” needs to include lifecycle management, not just rendering child output:
- Show a clear parent → child hierarchy with queued, running, completed, failed, and stopped states that remain accurate for background work, refreshes, reconnects, and mobile.
- Let me open a child independently to inspect its messages, tool calls, diffs, and file changes, then return to the parent.
- Let me stop, retry, or resume one child without accidentally stopping or settling the parent.
- Keep the parent visibly active while a child is still working, and surface child errors and results in the parent.
A useful first slice would be nested child threads with live status and drill-down; per-agent controls can follow. Without this, parallel delegation is difficult to supervise, and T3 Code can look idle while work is still happening.
@sudosapient I think this is how opencode does it?
Another good usage of this is implementing a
/btwcommand, so it starts a separate subagent with the existing context to answer whatever the user asked without interrupting the current flow. This would basically be a temporary fork/forktoo.- locked and limited conversation to collaborators
on Aug 15, 2026
Add support for codex subagents and render them as nested threads in the sidebar.
Subagents would ideally be independent chats that can be interacted with outside of the parent that spawned them.
This feature is supported by the codex app server.
Link to the commit in my fork: ratulsarna@4ae6de4