Summary
Codex multi-agent sessions should be modeled as real subagent relationships instead of surfacing raw <subagent_notification> JSON blobs as ordinary user messages in the transcript.
Problem
Codex sessions currently record subagent activity as a sequence like:
spawn_agent function call from the parent session
function_call_output containing the spawned agent_id
wait function call for that agent_id
function_call_output containing status keyed by agent_id
- a synthetic user
response_item whose content is wrapped in <subagent_notification>...</subagent_notification> and contains JSON like:
agent_id
status.completed / status.errored
Today, agentsview does not interpret that Codex-specific sequence as a subagent relationship. The visible symptom is that long raw JSON/status payloads show up in the User lane of the transcript.
That is semantically wrong in two ways:
- the notification is not a real user-authored message
- the spawned child agent is not linked into the existing subagent UI path
Current State
A stopgap local fix can hide <subagent_notification> rows as system/intermediate messages, but that is only a presentation band-aid.
The proper product behavior should reuse the existing subagent/session-linking model already used for other agent types:
tool_calls.subagent_session_id
relationship_type = "subagent"
- inline child transcript rendering from the originating tool call
- session tree grouping under the parent
Desired Behavior
For Codex sessions:
- Detect
spawn_agent as a subagent-spawning tool call.
- Extract the returned
agent_id from the matching function_call_output.
- Resolve that
agent_id to the spawned Codex child session.
- Annotate the originating tool call with
subagent_session_id.
- Reuse the existing transcript/sidebar subagent UI so the child session can be expanded inline and grouped correctly.
- Treat
<subagent_notification> messages as system/intermediate bookkeeping:
- either suppress them from the normal transcript
- or fold their final status into tool result/status presentation instead of showing raw JSON
Implementation Notes
Likely work items:
- extend Codex parsing to understand the
spawn_agent / function_call_output / wait / function_call_output sequence
- add Codex-specific mapping from spawned
agent_id to child Codex session ID
- annotate parsed tool calls with
subagent_session_id
- avoid storing or rendering raw
<subagent_notification> payloads as normal user transcript content
- ensure incremental sync does not lose Codex subagent mapping when the linking events arrive across sync boundaries
Acceptance Criteria
- raw
<subagent_notification> JSON no longer appears as a user message in Codex transcripts
- a parent Codex
spawn_agent call links to the actual child Codex session when the child session exists locally
- Codex child sessions participate in the existing subagent UI and sidebar grouping
- behavior works for both full parse and incremental sync
- regression tests cover:
- raw notification suppression/normalization
spawn_agent to child-session linkage
- incremental append cases where the linking events land after an earlier sync
Related Issues
Summary
Codex multi-agent sessions should be modeled as real subagent relationships instead of surfacing raw
<subagent_notification>JSON blobs as ordinary user messages in the transcript.Problem
Codex sessions currently record subagent activity as a sequence like:
spawn_agentfunction call from the parent sessionfunction_call_outputcontaining the spawnedagent_idwaitfunction call for thatagent_idfunction_call_outputcontaining status keyed byagent_idresponse_itemwhose content is wrapped in<subagent_notification>...</subagent_notification>and contains JSON like:agent_idstatus.completed/status.erroredToday,
agentsviewdoes not interpret that Codex-specific sequence as a subagent relationship. The visible symptom is that long raw JSON/status payloads show up in the User lane of the transcript.That is semantically wrong in two ways:
Current State
A stopgap local fix can hide
<subagent_notification>rows as system/intermediate messages, but that is only a presentation band-aid.The proper product behavior should reuse the existing subagent/session-linking model already used for other agent types:
tool_calls.subagent_session_idrelationship_type = "subagent"Desired Behavior
For Codex sessions:
spawn_agentas a subagent-spawning tool call.agent_idfrom the matchingfunction_call_output.agent_idto the spawned Codex child session.subagent_session_id.<subagent_notification>messages as system/intermediate bookkeeping:Implementation Notes
Likely work items:
spawn_agent/function_call_output/wait/function_call_outputsequenceagent_idto child Codex session IDsubagent_session_id<subagent_notification>payloads as normal user transcript contentAcceptance Criteria
<subagent_notification>JSON no longer appears as a user message in Codex transcriptsspawn_agentcall links to the actual child Codex session when the child session exists locallyspawn_agentto child-session linkageRelated Issues