›_ Codex Issues
Codex Issues / #36206

Duplicate Started entries for a single subagent in CLI 0.146.0

Open 💬 2 comments Opened Jul 30, 2026 by grig2277

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

Not recorded.

Which model were you using?

Not recorded.

What platform is your computer?

Linux 7.0.0-28-generic x86_64

What issue are you seeing?

The TUI renders two identical Started <agent-path> lines for one actual subagent. The unique agent tree contains one agent, so the duplicate notification is misleading.

Evidence from an isolated TUI session started with --no-alt-screen:

spawn_agent requested once: /root/ui_probe
Started /root/ui_probe
Started /root/ui_probe
unique agent listing: /root/ui_probe (one entry)

The same pattern occurred for three distinct subagents in a separate main session.

What steps can reproduce the bug?

  1. Run Codex CLI 0.146.0 in the TUI (for example, with --no-alt-screen).
  2. Call spawn_agent once to create one subagent.
  3. Observe the TUI notifications and list the active agents.

What is the expected behavior?

One Started <agent-path> entry per unique subagent.

Additional information

Possible regression (inference, not a confirmed root cause): PR #35363, merged shortly before rust-v0.146.0, emits both ItemStarted and ItemCompleted for one SubAgentActivity in commit af7f6f4. The observed TUI behavior may result if both events are rendered as Started; this has not been confirmed by maintainers.

View original on GitHub ↗

2 Comments

SamCod3 · 21 days ago

I can confirm this still reproduces with codex-cli 0.147.0 on Linux x86_64, and it is not limited to spawn notifications:

  • one spawn_agent call produces two identical Started <agent-path> lines;
  • one send_message or followup_task call produces two identical Interacted with <agent-path> lines.

This also matches #36897, which reports every subagent interaction being displayed twice on Windows.

For each affected call_id, the rollout contains one collaboration function_call and one persisted sub_agent_activity; it does not contain two agent operations or two activity records.

I traced the live path in rust-v0.147.0:

  1. emit_sub_agent_activity() emits the same TurnItem::SubAgentActivity through both emit_turn_item_started() and emit_turn_item_completed().
  2. The app-server forwards both lifecycle events.
  3. The TUI sends ItemStarted(SubAgentActivity) directly to on_sub_agent_activity() in handle_item_started_notification().
  4. ItemCompleted goes through handle_item_completed_notification() and then handle_thread_item() calls on_sub_agent_activity() again.
  5. on_sub_agent_activity() inserts a fresh history cell on every invocation, without deduplicating the item ID.

This makes the lifecycle change in af7f6f4 / #35363 the causal regression: it added ItemStarted for subagent activity timing while the TUI already rendered both started and completed items. The same render path was still present on main at 85e0661c when checked.

A minimal fix appears to be skipping history rendering for SubAgentActivity in handle_item_started_notification() and retaining the ItemCompleted path, which also keeps live rendering consistent with persisted/replayed history. A TUI regression test could feed paired ItemStarted/ItemCompleted notifications with the same ID and assert one history cell for both Started and Interacted activity kinds.

tanto30 · 11 days ago

Happens to me too