The main agent is not aware of subagents spawned before context compaction, and reports no way to list them by itself

Open 💬 3 comments Opened May 24, 2026 by Func86

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

Pro Lite

Which model were you using?

gpt-5.5 (reasoning xhigh, summaries detailed)

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 unknown

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

Windows Terminal

Codex doctor report

What issue are you seeing?

A subagent is spawned to review a set of new plan documents prepared by the main agent for the repo
The subagent finished, and the main agent updated the documents accordingly
Context compacted automatically on the main agent
The main agent did a diff review pass and reported to me
I asked the main agent, "Can you get back with that subagent and allow one more round of review?"
The main agent created a new subagent session instead, forking from the main session with all conversations between the main agent and me
I noticed the issue and questioned the main agent; it reports that "the original subagent id was not available in the compacted context I had"
I followed up further, and it reports "I can’t retrieve a list of prior spawned sessions with the tools currently exposed. I can only act on an agent id I already know."
With the subagent ID provided by me from the /agents command, it can then resume the subagent and proceed correctly.

I see this as a mix of multiple issues:

Awareness of previously spawned subagent IDs may not survive context compaction. I guess this is acceptable/expected if the subagent is not active.
There is no way for the main agent to list previously spawned subagents when a resume is the correct orchestration.
In this case, the main agent has the choice to resume the previous subagent (if the ID is available), start a fresh subagent session, or fork the main session with the user. It chose the worst action possible, since this subsequent "review" is not unbiased (as the user requested) at all, with the full conversation history between it and the user.

What steps can reproduce the bug?

Uploaded thread: 019e56bf-f74a-7de1-b0eb-46853ce69173

What is the expected behavior?

The agent should be able to list previously spawned subagents, and actively resume these sessions if beneficial.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

#23479
#24150

Powered by Codex Action

yui-stingray · 3 months ago

One current-main data point from openai/codex@7d47056: there are now two related surfaces, but neither fully proves this repro is closed.

On the client side, app-server exposes thread/loaded/list, and the TUI uses it after resume/fork/new to backfill the /agent picker from loaded threads. On the model/tool side, multi-agent v2 also has a list_agents tool that lists live agents in the current root thread tree.

The caveat is that this still looks scoped to live/loaded agents: the tool description says “live agents”, and the existing tests cover omitting closed agents. So if the missing case is a prior closed or unloaded subagent after compaction, or if the reporter is on 0.133.0 before this tool is available to the model, the issue still seems useful. I would narrow the ask to making prior resumable subagents discoverable to the model, not just visible in the TUI.

Func86 · 3 months ago

It really likes to fork the main session.

› You forked our conversation. why?


• Closed Bacon

• I forked because the subagent tool says to use fork_context: true when the subagent should have exactly the same context. For a staged-change review
  against the whole plan, I chose that so it could see the prior decisions.

  That was a bad call in this workspace because your AGENTS.md explicitly says “Do not fork the main session with the user to start subagents.” I missed
  that constraint while following the tool guidance. I’ve shut the subagent down and won’t use a forked subagent here again.


› Do you know what is "unbiased review" about?


• Yes. “Unbiased review” means the reviewer should not inherit my assumptions, my implementation rationale, or the conversational framing that might make
  them defend the change.

  For this request, the better setup would have been:

  - spawn a reviewer without fork_context
  - give only the objective artifacts: repo path, staged diff, plan doc path, and review criteria
  - ask them to inspect the code independently and report findings
  - no edits, no knowledge of my prior explanations beyond what is written in docs/code

  By forking the conversation, I biased the reviewer with all previous discussion and my own decisions. That undermined the point of asking for an unbiased
  review.