[App] Show source-task relationships in the pinned summary alongside "Created tasks"

Open 💬 1 comment Opened Aug 23, 2026 by iamhectorlopez

What variant of Codex are you using?

App for macOS, version 26.818.41509 (build 6962).

What feature would you like to see?

Summary

Please make the pinned summary a persistent navigator for the current task's source and direct task relationships.

The pinned summary already includes Created tasks and Subagents. The missing side is inbound provenance: after a task is delegated, forked, or started from another task, its source link is easy to lose because that context lives only in transcript or activity UI.

Proposed behavior

Show the applicable relationships in the pinned summary:

Surface the source task behind Sent by Codex from another task and make it navigable.
Show Parent chat for a subagent's agent thread.
Show Continued from chat for a fork's source chat.
Keep the existing Created tasks section and its Starting, Working, Done, and Failed statuses.
Keep completed agent threads discoverable under Subagents / Done.
Show Forked chat relationships created from the current chat.
When Voice has moved between tasks, preserve a navigable link to the previous voice task.
Show the related task or chat title, relationship, status, and project when relevant.
Open the related task or chat when selected.
If a relationship list is truncated, provide an expandable way to view older entries.

Please keep the relationship types distinct rather than treating every related task as a parent or child.

Why this helps

ChatGPT Voice can start separate Codex threads, check them, send follow-up instructions, and bring progress or results back to the voice conversation. Codex also has separate subagent and fork workflows.

Today, those relationships are distributed across labels such as Created task, Sent to {title}, Update from {title}, Returned from {title}, Parent chat, and Continued from chat. The pinned summary is the natural persistent place to answer:

Where did this task come from?
What tasks, forks, or agent threads did it create?
Which task sent the current work?
Where should I navigate to review the originating context?

Scope

This is not a request to merge task transcripts or make every relationship a parent/child relationship. Side chats are not the focus.

It is also not a request to use handoff as the umbrella: handoff_thread moves the same task between environments or hosts rather than representing task ancestry or cross-task messaging.

Additional information

The current App distinguishes these relationships internally:

Cross-task delegation: sourceThreadId, displayed as Sent by Codex from another task
Native subagent ancestry: parentThreadId, displayed as Parent chat
Fork ancestry: forkedFromId, displayed as Continued from chat

Please preserve these distinctions while surfacing them together in the pinned summary.

Official documentation:

Voice task coordination: https://learn.chatgpt.com/docs/features/voice
Subagent workflows and agent threads: https://learn.chatgpt.com/docs/agent-configuration/subagents
App Server thread relationships: https://github.com/openai/codex/blob/main/codex-rs/app-server/README.md

Related but broader or different:

#32017 — durable parent/child task workflows and summarized handoffs
#35966 — Voice/text task ownership and coordination
#38908 — stale status in the pinned summary

View original on GitHub ↗

1 Comment

dongkeren · 4 days ago

This is an important distinction. Delegation source, subagent ancestry, fork lineage, and handoff are not different labels for the same parent/child relationship. They answer different questions about provenance, execution topology, history, and identity.

The deeper requirement, in my view, is that these relationships remain typed, durable facts that a client can recover after restart, rather than presentation inferred from transcript text.

We ran into the same boundary while designing KFD, an open model for durable agent Work. KFD treats Work as distinct from any individual thread and keeps provenance, delegation, continuation, and lineage as typed durable relationships. Kungfu is our first-party implementation of that model, so this distinction is operational rather than only conceptual.

We reduced the broader question to six paired “successful run” cases in KFD #427. Each pair looks equally successful at the thread or execution level, but differs at the Work level. The relationship distinctions identified here are part of what a protocol needs to preserve in order to tell such cases apart.

For this issue, the immediate implication is narrower: the client should be able to recover these typed relationships after restart without parsing transcript text.