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?
- Start a normal Codex TUI thread.
- Spawn a role-specific subagent with
spawn_agent, e.g. an architecture reviewer.
- Wait for the subagent to complete.
- Continue the broader task in what appears to be the same UI/session.
- 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 threadagent_role=odoo-architectagent_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=openthreads 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:
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-architectsubagent, 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-architectchild 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?
spawn_agent, e.g. an architecture reviewer.agent_rolestill 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 theparent.
Additional information
Local evidence
Parent session:
cliagent_rolespawn_agent(agent_type="odoo-architect")wait_agentChild session:
session_meta.source.subagent.thread_spawn.parent_thread_idpoints to the parent threadagent_role=odoo-architectagent_nickname=Lovelacestate_5.sqlite.thread_spawn_edgesstill had the parent -> child row withstatus=openthreadstable showed the child unarchived and recently updatedThe 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: