Before submitting
Area
apps/web
Summary
In the T3 Code desktop conversation timeline, two app-owned Codex children launched by a Claude parent were absent from the visible conversation after the parent finished its launching turn. The footer still reported two pending subagents. The user reports that the cards initially appeared and then disappeared. A later screenshot shows a failed child and a running retry after a child failure resumed the parent. This prevents the user from monitoring individual children while the parent waits.
Steps to reproduce
These are the known incident conditions, not a deterministic reproduction executed by this investigator. Use the installed baseline under Runtime or environment.
- Open a Claude parent conversation and ask it to delegate two background tasks to the default Codex instance using
gpt-6.1-sol with reasoningEffort=high. In the observed conversation, the parent called mcp__t3-code__delegate_task twice. The task subject and private local note are omitted because they are unnecessary to describe the visibility failure. A generic task substitute has not been tested.
- Let the parent finish its launching turn while both children continue in the background. The observed parent also had one background command pending.
- Inspect the main conversation timeline and waiting footer. In the supplied waiting screenshot,
Worked for 37s and the parent's confirmation that both Codex children are running are visible. The footer says Waiting on 2 subagents and 1 command, but the child activity cards are absent from that visible response.
- Compare the later view after one child reaches a terminal state and the parent resumes. In this incident the child failed, the parent checked its status, and the parent launched a retry. The later screenshot shows the failed child card and the running retry card.
One incident is supported by two supplied screenshots and a read-only recovery of its stored state. No fresh UI attempt, fold-expansion test, navigation test, or reload test was run. The exact interaction or state update that first hid the cards is unknown.
Expected behavior
Live app-owned child tasks remain visible and inspectable in the parent conversation while they are running or waiting, including after the launching parent turn finishes. Folding settled parent work must not hide the only per-child activity cards while the footer still counts those children as pending. Each card should continue to reflect its own lifecycle, so completion of the parent turn does not make active children appear to have vanished.
Actual behavior
The user reports seeing the Codex children initially and then losing their cards. The first supplied screenshot shows the parent waiting on two subagents and one command with no child cards visible in that response. The second supplied screenshot shows a failed Codex child and a running retry in the later response. The failed card displays stream disconnected before completion: stream closed before response.completed.
The recovered store confirms that these were registered app-owned Codex children, rather than only an assistant claim about delegation. Both original children belong to a parent run that completed while the children continued in the background. One subsequently failed and produced a continuation that launched the retry. The disconnect is reported as part of that sequence; this report does not establish that it caused the visibility problem. Read-only state inspection confirmed child records and model options. It did not reproduce the UI failure or prove provider-process liveness.
Evidence
- Expected source: The existing per-child cards and waiting footer shown in the supplied screenshots establish the activity-monitoring UI for delegated tasks. The user's incident description establishes that those cards had already been visible. The expected persistence of live cards is a user-facing monitoring contract inferred from this existing UI, rather than an explicit published guarantee about folding.
- Failure source: Supplied Screenshot A is the waiting view with
Worked for 37s, the parent confirmation, and Waiting on 2 subagents and 1 command, with no child cards in that response. Supplied Screenshot B is the later view with the failed child and running retry. The user explicitly reports initial appearance, disappearance, and subsequent reappearance. Original screenshots are not attached publicly because they contain unrelated private conversation content; the relevant UI text and state are transcribed here.
- Evidence provenance: supplied
- Local verification: not-run
- Reproduction completeness: incomplete
- Missing fact: The precise UI interaction or state transition that initially removed the already-visible cards, and a fresh reproduction using generic task content, have not been captured.
Read-only state recovery adds the following observed supporting evidence. Task names, identifiers, paths, and absolute timestamps are omitted. Times are relative to the first child's stored start and are approximate.
| Relative time |
Stored observation |
| 0 seconds |
Child A starts with origin=app_owned, provider=codex, and status=running. |
| 6 seconds |
Child B starts with the same origin and provider. |
| 8 seconds |
The launching parent run completes. Both original children remain associated with that run. |
| 82 seconds |
Child B reaches status=failed with the same stream-disconnect text shown in Screenshot B. A new parent continuation starts. |
| 97 seconds |
The continuation starts Child B's retry with origin=app_owned and status=running. |
| At the recovery snapshot |
Child A and Child B's retry are stored as running. The original Child B is failed. Both parent runs are completed. |
Each original child and the retry has a persisted child-thread model selection of instanceId=codex, model=gpt-6.1-sol, and options=[{id: reasoningEffort, value: high}].
Supporting source inspection, not proof of the installed cause: current timeline folding logic groups subagent events by their launching run, derives the unsettled run from the parent lifecycle, and includes pre-answer subagent entries in a completed-turn fold. The persistent-resource exemption in apps/web/src/session-logic.ts:322 excludes subagents. This makes settled-run folding a plausible explanation for the supplied sequence. The inspected source revision has not been matched to the installed bundle, and no implementation change is prescribed.
Restoration check
Repeat the known cross-provider launch with two app-owned Codex children and capture the missing initial transition. After the launching parent turn finishes, confirm that both children remain visible and inspectable while the waiting footer counts them. Confirm the same behavior through a later parent continuation and a child retry. Each card must reflect its own running, failed, or completed state. As a control, ordinary settled parent command and reasoning entries should still be eligible for folding. Expanding all completed turns by default would not independently establish that live child visibility follows the child's own lifecycle.
Runtime or environment
Installed desktop application version, read from the running application's bundle: 0.0.46-nightly.20261006.2735.
The incident occurred in the T3 Code Nightly desktop app on macOS 27.0. The parent used claude-opus-5-5, high effort, with the 1M context option and full access. The delegated children used the default Codex instance and model options described above. The Codex CLI found on the serving host reported 0.160.1; the worker's exact executable has not been independently matched. Thread state was recovered from the serving host's active v2 SQLite store with read-only access. The installed application commit is unknown.
Impact
Minor bug or occasional failure. The supplied incident loses per-child monitoring during a legitimate cross-provider background-task workflow. It does not establish that task execution stops, that data is lost, or that every delegation is affected.
Workaround
No verified workaround. A later parent continuation made a failed child and its retry visible in the supplied incident. Manually expanding the completed Worked for row may expose folded cards, but that action has not been tested and is not claimed to restore persistent live monitoring.
Triage assessment
- Impact level: P2
- Assessment status: supported
- Impact basis: The supplied incident shows a consequential loss of per-child visibility while registered background children are pending. Execution failure caused by the hidden cards, data loss, broader frequency, and population reach are not established.
- Workaround status: unverified
- Workaround basis: The later screenshot restores visibility for a failed child and a retry, but it does not establish a user-controlled workaround for all active children. Expanding the completed turn has not been tested.
Before submitting
Area
apps/web
Summary
In the T3 Code desktop conversation timeline, two app-owned Codex children launched by a Claude parent were absent from the visible conversation after the parent finished its launching turn. The footer still reported two pending subagents. The user reports that the cards initially appeared and then disappeared. A later screenshot shows a failed child and a running retry after a child failure resumed the parent. This prevents the user from monitoring individual children while the parent waits.
Steps to reproduce
These are the known incident conditions, not a deterministic reproduction executed by this investigator. Use the installed baseline under Runtime or environment.
gpt-6.1-solwithreasoningEffort=high. In the observed conversation, the parent calledmcp__t3-code__delegate_tasktwice. The task subject and private local note are omitted because they are unnecessary to describe the visibility failure. A generic task substitute has not been tested.Worked for 37sand the parent's confirmation that both Codex children are running are visible. The footer saysWaiting on 2 subagents and 1 command, but the child activity cards are absent from that visible response.One incident is supported by two supplied screenshots and a read-only recovery of its stored state. No fresh UI attempt, fold-expansion test, navigation test, or reload test was run. The exact interaction or state update that first hid the cards is unknown.
Expected behavior
Live app-owned child tasks remain visible and inspectable in the parent conversation while they are running or waiting, including after the launching parent turn finishes. Folding settled parent work must not hide the only per-child activity cards while the footer still counts those children as pending. Each card should continue to reflect its own lifecycle, so completion of the parent turn does not make active children appear to have vanished.
Actual behavior
The user reports seeing the Codex children initially and then losing their cards. The first supplied screenshot shows the parent waiting on two subagents and one command with no child cards visible in that response. The second supplied screenshot shows a failed Codex child and a running retry in the later response. The failed card displays
stream disconnected before completion: stream closed before response.completed.The recovered store confirms that these were registered app-owned Codex children, rather than only an assistant claim about delegation. Both original children belong to a parent run that completed while the children continued in the background. One subsequently failed and produced a continuation that launched the retry. The disconnect is reported as part of that sequence; this report does not establish that it caused the visibility problem. Read-only state inspection confirmed child records and model options. It did not reproduce the UI failure or prove provider-process liveness.
Evidence
Worked for 37s, the parent confirmation, andWaiting on 2 subagents and 1 command, with no child cards in that response. Supplied Screenshot B is the later view with the failed child and running retry. The user explicitly reports initial appearance, disappearance, and subsequent reappearance. Original screenshots are not attached publicly because they contain unrelated private conversation content; the relevant UI text and state are transcribed here.Read-only state recovery adds the following observed supporting evidence. Task names, identifiers, paths, and absolute timestamps are omitted. Times are relative to the first child's stored start and are approximate.
origin=app_owned,provider=codex, andstatus=running.status=failedwith the same stream-disconnect text shown in Screenshot B. A new parent continuation starts.origin=app_ownedandstatus=running.Each original child and the retry has a persisted child-thread model selection of
instanceId=codex,model=gpt-6.1-sol, andoptions=[{id: reasoningEffort, value: high}].Supporting source inspection, not proof of the installed cause: current timeline folding logic groups subagent events by their launching run, derives the unsettled run from the parent lifecycle, and includes pre-answer subagent entries in a completed-turn fold. The persistent-resource exemption in
apps/web/src/session-logic.ts:322excludes subagents. This makes settled-run folding a plausible explanation for the supplied sequence. The inspected source revision has not been matched to the installed bundle, and no implementation change is prescribed.Restoration check
Repeat the known cross-provider launch with two app-owned Codex children and capture the missing initial transition. After the launching parent turn finishes, confirm that both children remain visible and inspectable while the waiting footer counts them. Confirm the same behavior through a later parent continuation and a child retry. Each card must reflect its own running, failed, or completed state. As a control, ordinary settled parent command and reasoning entries should still be eligible for folding. Expanding all completed turns by default would not independently establish that live child visibility follows the child's own lifecycle.
Runtime or environment
Installed desktop application version, read from the running application's bundle:
0.0.46-nightly.20261006.2735.The incident occurred in the T3 Code Nightly desktop app on macOS 27.0. The parent used
claude-opus-5-5, high effort, with the 1M context option and full access. The delegated children used the default Codex instance and model options described above. The Codex CLI found on the serving host reported0.160.1; the worker's exact executable has not been independently matched. Thread state was recovered from the serving host's active v2 SQLite store with read-only access. The installed application commit is unknown.Impact
Minor bug or occasional failure. The supplied incident loses per-child monitoring during a legitimate cross-provider background-task workflow. It does not establish that task execution stops, that data is lost, or that every delegation is affected.
Workaround
No verified workaround. A later parent continuation made a failed child and its retry visible in the supplied incident. Manually expanding the completed
Worked forrow may expose folded cards, but that action has not been tested and is not claimed to restore persistent live monitoring.Triage assessment