Subagent support as nested threads

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

Let me know if I could raise a PR for this.

Do you support max_depth settings, e.g. when subagents can spawn more subagents?

BTW Would love this! ❤️

@BleedingDev

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)

This 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 CLI

I created this exact thing in my fork, still testing, will push soon.

Linked 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

Thanks 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

@sudosapient I think this is how opencode does it?

Another good usage of this is implementing a /btw command, 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

/fork too.

Navigation Menu

Repository navigation

Subagent support as nested threads #538

Summary of behavior changes

Video example

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Subagent support as nested threads #538

Description

Activity

ratulsarna commented on Mar 9, 2026

BleedingDev commented on Mar 9, 2026

ratulsarna commented on Mar 9, 2026

BleedingDev commented on Mar 9, 2026

maria-rcks commented on Mar 22, 2026

jeroenev commented on Mar 31, 2026

0xpaperhead commented on May 1, 2026

Quicksaver commented on Jun 9, 2026

Summary of behavior changes

Video example

juliusmarminge commented on Jun 20, 2026

sudosapient commented on Aug 1, 2026

shubham-cpp commented on Aug 5, 2026

icaroryan commented on Aug 10, 2026

cardoso-neto commented on Aug 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions