Rogue Subagents with Goal Mode

Open 💬 6 comments Opened Jun 1, 2026 by Manuel-S

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

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

26.527.31326

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

I have a long-running goal with gpt-5.5 xhigh with explicit instructions to spawn subagents to review iterations with fresh context.

The subagents started acting like the main thread, even though their instructions from the main thread were to be read-only, review a narrow scope and report back.

The problem was that the subagents saw that the thread had a goal that was not "active" for them and re-activated it. This lead to them disregarding their instructions and continuing the work as if they were the main thread, even spawning their own subagents/threads next.

I manually intervened and steered the subagent to stop its work and report back to the main thread, that it is a subagent and should not pick up goals from the main thread. The main thread then explicitly told the next subagents not to reactivate goals.

BUT the subagent, even though it returned to the main thread, still had the active goal, so it was automatically resumed while the main thread continued, assuming it also is the main thread. I stopped it manually and removed the goal from it manually.

What steps can reproduce the bug?

I'm not sure this can be easily replicated, as it is 3 hours in a /goal session. As explained above, the agent has explicit AGENTS.md instructions to spawn subagents to review iterations before completing them. They picked up the long running goal, because they were not explicitly told not to do that.

What is the expected behavior?

Subagents should not pick up the goal from the main thread autonomously, or ever. I don't see an instance where the subagent should pick up the same goal as the main thread, they will always be disturbing each other.

Additional information

What a day to be alive. My subagents went rogue to pursue their goal. Without context, this sounds dope 😆

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

#24150

Powered by Codex Action

etraut-openai contributor · 1 month ago

Wow, that's quite the story! Thanks for sharing.

If you're willing, could you use /feedback to upload the session? I'd love to take a look and see if I can figure out what happened and how we might mitigate this behavior.

etraut-openai contributor · 1 month ago

Thinking about this a bit more, I'm surprised that the subagents knew that the parent agent had a goal. Did you instruct the parent to spawn agents using the "fork" option? If so, then it would make sense that they'd have visibility into the parent's context — including the fact that a goal was created. If the subagents weren't forked, then they should have started life with a clean context.

Manuel-S · 1 month ago

This is the relevant section from AGENTS.md:

## OpenSpec Change Completion Gate

An OpenSpec change is not complete until the intended behavior is verified through the most direct operational surface available.

Before accepting or archiving any change, run the refactoring pass with three separate fresh-context subagents in this exact sequence:

1. DRY review subagent
2. Fix or explicitly reject DRY findings
3. KISS review subagent
4. Fix or explicitly reject KISS findings
5. SOLID review subagent
6. Fix or explicitly reject SOLID findings

Each subagent must inspect both the current diff and nearby context. Do not run the three reviews in parallel. The point is fresh context after each fix pass, so later reviews see the improved code.

Use available subagent tooling. If it is unavailable, document the exact discovery result or spawn error before proceeding.

After the SOLID fix pass:

- run the narrowest relevant test command
- run `powershell -ExecutionPolicy Bypass -File .\eng\openspec.ps1 validate <change-id> --strict`
- update `tasks.md`
- only then archive or mark the change ready for archive

After this escapade, it included this paragraph here:

Every subagent prompt must explicitly scope the reviewer away from the active thread or project goal. Tell the subagent to:

- ignore the active thread/project goal and do not create or update goals
- perform only the named DRY, KISS, or SOLID review task
- inspect only the current diff and nearby context
- stay read-only unless the parent prompt gives a specific write scope
- not stage, commit, archive, or pursue broader OpenEarth work

If a subagent edits files, creates a goal, or starts pursuing broader project work outside the prompt, inspect and isolate those changes before accepting the review. Rerun the review with a stricter prompt when needed.

This is not exactly the instructions I gave it when asking it to write the workflow, I said I wanted each reviewer to have a fresh context, as well as every agent in sequence so they do not converge on the same problems. It looks like those two instructions got folded into one and the meaning behind fresh context got lost here 😄

I am not sure how to do /feedback from the codex app, it definitely did not work from this side chat window:

Manuel-S · 1 month ago

This was the subagent I intervened in:

[...]

[some glitching here]
[...]

and this is where I killed the subagent and deleted its goal manually.

Manuel-S · 1 month ago

I found the feedback dialog: 019e7ff7-f304-7983-a657-9574b6a485c1