[App][Subagents] Long-running command card disappears after child-thread rebind; output deltas are dropped

[Zhuang-Zhuang-Liu]

What version of the Codex App are you using (From “About Codex” dialog)?

26.727.51351 (build 6119)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When a sub-agent runs a long-lived command that streams progress and is polled until completion, the Codex Desktop Subagents panel can omit the entire Ran a command card. The backend command completes successfully and the raw session contains the command plus every output chunk, but the child thread UI shows only the initial assistant message and the final JSON/result message.

The Desktop log for one affected child recorded 31 instances of:

Dropping commandExecution/outputDelta for missing item

The same child initially logged:

Received turn/started for unknown conversation

The app then performed thread/read and logged Rebinding placeholder latest turn to incoming event, but the active commandExecution item was not restored. All subsequent progress deltas referenced a missing command item, so no command card or live output could be rendered.

The command itself was healthy: its raw session showed the initial invocation, repeated polling calls, progress from 0% through 100%, exit code 0, and the final artifact. Only the renderer presentation was missing.

What steps can reproduce the bug?

1. Open Codex Desktop on macOS.
2. Start a task that spawns a single sub-agent.
3. Have that sub-agent execute a command that runs longer than the initial tool yield and prints periodic progress, so the command continues as a process session and is polled. A minimal equivalent is:

python -u -c 'import time; [(print(f"progress {i}/24", flush=True), time.sleep(10)) for i in range(1, 25)]'

4. Keep the Subagents panel open and inspect the child thread while the command runs.
5. After completion, inspect the child thread and the Desktop log.

Observed result:

• The child thread displays its starting assistant message and final result.
• No Ran a command card is displayed.
• The raw session contains the command and all progress/output.
• The Desktop log repeatedly reports Dropping commandExecution/outputDelta for missing item for the command item.

Short commands that return within one tool call do not reliably reproduce this. The failure is easier to observe when execution exceeds the first yield and produces multiple streamed/polled output deltas.

Session and conversation identifiers are omitted from this public report. Redacted correlated excerpts can be provided if needed.

What is the expected behavior?

The child thread should display its Ran a command card and append streamed output throughout execution.

If the renderer receives a child event before the child conversation is registered, it should queue/replay the event or fully reconstruct the turn and its active command items during thread/read/rebind. Rebinding the turn must not leave later commandExecution/outputDelta events pointing to a missing item.

Additional information

This appears related to #23292 and especially #32737, but the visible failure here is narrower: the child completes normally and remains visible, while only its command/tool card and streamed command output are lost.

Version comparison from the same machine:

• Codex App release 26.727.40816: an affected long-running rollout dropped 11 command output events.
• Codex App release 26.727.51351 (build 6119): an affected long-running rollout dropped 31 command output events.

Therefore the issue is still present in 26.727.51351. Changing the workspace directory and creating multiple sequential sub-agents were investigated and are not required triggers. The stronger correlation is a newly hydrated child thread running a long-lived command with repeated output deltas.

Privacy: project paths, prompts containing user data, command arguments, conversation IDs, session IDs, and task artifacts have been omitted.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history #35727

Powered by Codex Action

[Zhuang-Zhuang-Liu]

I reviewed #35727. The two reports likely involve the same renderer rehydration/reconciliation subsystem, but the reproduction conditions and visible failure are different.

• Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history #35727 requires Remote Control plus a relay/WebSocket sequence gap or reconnect, and the viewer transcript remains partially rendered.
• [App][Subagents] Long-running command card disappears after child-thread rebind; output deltas are dropped #36602 reproduces locally within a single Codex Desktop instance, without Remote Control, a network interruption, or multiple app-server instances. The sub-agent thread remains visible and its final assistant message renders correctly, but the active commandExecution item is missing. The renderer receives subsequent output deltas and explicitly drops them with Dropping commandExecution/outputDelta for missing item.

This therefore appears to be a separate local sub-agent trigger for the same broader renderer-state recovery problem. I’ll keep this issue open unless maintainers prefer to consolidate the reports.

---

我已经检查了 #35727。两者可能涉及同一套 renderer 状态恢复/对账逻辑，但复现条件和用户可见故障不同。

• Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history #35727 需要 Remote Control，并伴随 relay/WebSocket sequence gap 或重连；viewer 中的对话记录停留在不完整状态。
• [App][Subagents] Long-running command card disappears after child-thread rebind; output deltas are dropped #36602 可在单个本地 Codex Desktop 实例中复现，不需要 Remote Control、网络中断或多个 app-server 实例。sub-agent 线程仍然可见，最终 assistant 消息也能正常显示，但活动的 commandExecution item 丢失；renderer 已收到后续输出增量，却以 Dropping commandExecution/outputDelta for missing item 明确将其丢弃。

因此，这更像是同一类 renderer 状态恢复问题在本地 sub-agent 场景下的独立触发路径。我会暂时保留该 issue，除非维护者希望合并处理。

[Zhuang-Zhuang-Liu]

Additional finding: there appears to be a second completed-history hydration path that produces the same missing tool-card UI, even when the affected child does not log Dropping commandExecution/outputDelta for missing item.I reproduced this on the same App build with a single subagent created using fork_turns="none":1. The child first completed a tool-free READY turn.2. I sent a follow-up to the same child.3. The child ran a long rollout command, including the initial exec call and repeated polling calls, and exited successfully.4. The raw child JSONL contains the full sequence of custom_tool_call / command execution records, outputs, progress updates, exit code 0, and the final artifact.However, after completion, querying that child through thread/read with outputs requested returned only assistant-message items:json{ "turns": [ { "status": "completed", "items": [{ "type": "agentMessage", "text": "{final result JSON}" }] }, { "status": "completed", "items": [{ "type": "agentMessage", "text": "READY" }] } ]}No commandExecution, tool-call, polling, or command-output items were present in the read result. The Desktop subagent details pane consequently showed exactly READY and the final JSON, but none of the command cards.I also checked a separate one-turn child with no READY/follow-up pattern: after it completed, thread/read again returned only the final assistant message and omitted its command item. So this is not specific to the two-phase workaround.This suggests two related failure modes:1. Live child events arrive before conversation/item registration and command output deltas are dropped.2. Completed child history hydration via thread/read omits tool/command items, so reopening or refreshing the child thread cannot reconstruct the cards even when the raw session is complete and no live-delta drop is logged.Expected behavior: thread/read (or the renderer's reconciliation path) should preserve/return completed commandExecution and tool-call items, including their outputs, rather than returning only assistant messages.I can provide redacted raw-session and Desktop-log excerpts if useful.