Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix User turns can continue in completed subagent thread after parent spawned it, leaving subagent role active

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

Pro

Which model were you using?

GPT-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

What issue are you seeing?

After a parent thread spawned an odoo-architect subagent, later user turns were appended to the child subagent thread instead of the original parent thread. From the user's perspective, the conversation looked like the same ongoing task, but the active thread was the subagent and retained the subagent role/persona.

This caused the assistant to behave as the odoo-architect child after the original architecture review was complete, including following the child agent's KB/review instructions in later unrelated turns.

What steps can reproduce the bug?

  1. Start a normal Codex TUI thread.
  2. Spawn a role-specific subagent with spawn_agent, e.g. an architecture reviewer.
  3. Wait for the subagent to complete.
  4. Continue the broader task in what appears to be the same UI/session.
  5. Observe that later user turns can be appended to the child subagent thread, with the child agent_role still active.

What is the expected behavior?

After the parent receives a completed subagent result, normal user turns should continue in the parent thread unless the user explicitly switches/resumes the child thread.

A completed child subagent should not remain the active conversation target for unrelated future user turns.

The UI/history should make it clear when the active thread is a subagent, and resume last / recent-thread selection should not silently continue in a completed child thread when the user expects the parent.

Additional information

Local evidence

Parent session:

  • source: cli
  • no agent_role
  • spawned child via spawn_agent(agent_type="odoo-architect")
  • received the child result via wait_agent
  • parent stopped updating after the branch split work

Child session:

  • session_meta.source.subagent.thread_spawn.parent_thread_id points to the parent thread
  • agent_role=odoo-architect
  • agent_nickname=Lovelace
  • the child rollout continued receiving normal user messages for several hours after the architecture review completed
  • state_5.sqlite.thread_spawn_edges still had the parent -> child row with status=open
  • threads table showed the child unarchived and recently updated

The concrete result was that user messages like "where are we now?" and later implementation/smoke-test instructions were recorded in the child subagent thread, not the parent.

Related issues

This appears related to, but not identical to:

  • #17487: resume/replay can surface stale assistant final message from subagent history
  • #13119: TUI state not persisting correctly across subagent thread switching
  • #16226: hook events lack subagent/main-session discriminator

extent analysis

TL;DR

The issue can be addressed by ensuring that the parent thread is correctly resumed after a child subagent completes, potentially by updating the thread management logic to handle subagent completion and user input routing.

Guidance

  • Review the wait_agent function to ensure it properly handles the completion of a child subagent and updates the parent thread accordingly.
  • Verify that the session_meta and threads tables are correctly updated when a child subagent completes, to prevent the child thread from remaining active.
  • Investigate the state_5.sqlite.thread_spawn_edges table to determine why the parent -> child row remains with status=open after the child subagent completes.
  • Consider adding a check to ensure that user input is routed to the correct thread (parent or child) based on the current conversation state.

Example

No code snippet is provided as the issue description does not include specific code references.

Notes

The issue appears to be related to thread management and conversation state handling. The provided information suggests that the child subagent thread is not being properly closed or deactivated after completion, causing subsequent user input to be appended to the child thread instead of the parent thread.

Recommendation

Apply a workaround to ensure that the parent thread is correctly resumed after a child subagent completes, such as by manually updating the thread management logic or adding a check to route user input to the correct thread. This will help prevent the child subagent thread from remaining active and causing unexpected behavior.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#file not found#serialization error#model compatibility#GPU setup#container setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix User turns can continue in completed subagent thread after parent spawned it, leaving subagent role active