Hierarchical thread namespaces with explicit parent-context inheritance across devices

[jennyzhou245-rgb]

I would like to organize user-created threads into a collapsible hierarchy and reuse shared context from a parent thread:

A — shared background, constraints, and decisions
  A/A1 — first focused task
  A/A2 — second focused task
B
  B/B1

A parent should remain a normal conversation that I can continue independently.

Desired behavior:

• Create a child from an existing thread, or choose a parent when creating a thread.
• Expand/collapse branches and navigate using a namespace-style breadcrumb.
• Rename and reorganize threads without breaking their identity or links.
• Explicitly choose whether a child inherits parent context.
• Show exactly which parent content and revision the child received.
• Keep sibling conversations separate; child activity should not automatically modify the parent.

For an initial implementation, I suggest inheriting a snapshot at creation, with an explicit “Refresh from parent” action later. A snapshot could use selected messages or a reviewed summary, with any truncation clearly disclosed. Moving a thread in the sidebar should not silently change its context source.

Hierarchy and context references should persist on the server so desktop, web, and mobile clients connected to the same environment see consistent data. Older clients should retain basic thread access where possible, and unsupported operations should have clear capability checks. Cross-environment inheritance could be deferred.

Related work:

• Thread folders: Add user-defined thread folders to the sidebar #3071, closed without merging; its proposal used local-only persistence.
• Nested subagent discussion: Subagent support as nested threads #6689
• Nested subagent UI PRs: feat(sidebar): reveal nested subagent threads #3861 and feat(mobile): nested subagent threads behind a toggle #3871, both closed without merging.

My use case is manually organizing long-running conversations around shared background. Both hierarchy and explicit context reuse matter.

Would this direction fit the roadmap? If so, would you prefer separate, scoped proposals for server-persisted hierarchy and parent-context snapshots before any implementation PR?