Codex ignores explicit delegation-only instructions and duplicates delegated research in parent thread
Summary
On April 17, 2026, in thread 019d9aa2-7ff7-7e30-848c-bfe8f70dd8a1, Codex did not reliably respect explicit user instructions about delegation boundaries.
When I explicitly asked it to delegate research to a subagent so the parent thread would not bloat its context, it launched the agent and then still performed the same research itself in the parent thread.
Earlier in the same session, a local workflow/skill expected a checker/context-checker agent run, but Codex claimed a higher-priority rule prevented that. That restriction was not visible in the local skill files, repo AGENTS.md, or my visible ~/.codex/config.toml.
This makes multi-agent orchestration feel unreliable and defeats the purpose of delegation.
Environment
- Observed date: April 17, 2026
- Thread uploaded via
/feedback:019d9aa2-7ff7-7e30-848c-bfe8f70dd8a1 - Local Codex version cache showed latest version
0.121.0at the time of filing - Running in a Codex terminal/agent workflow environment with subagent support
Repro
- Use a workflow or skill file that explicitly expects a subagent launch.
- Ask Codex to investigate something using a delegated research agent because you do not want the parent thread to accumulate that research context.
- Clarify if needed that by “search it up” you specifically mean “delegate an agent to do the research.”
- Observe that Codex may still do local/web research itself in the parent thread after launching the agent.
- Also observe that Codex may claim a higher-priority restriction on subagent use that is not visible from normal local repo/config surfaces.
Expected behavior
- If the user explicitly requests agent-only delegation, the parent should not also perform the same research unless the user asked for parallel verification.
- If a higher-priority instruction conflicts with local workflow/skill instructions, Codex should surface that conflict before acting.
- Delegation policy that materially changes behavior should be auditable from normal config or session surfaces.
Actual behavior
- Delegation boundaries were not followed tightly.
- Parent-thread research duplicated work that had already been delegated.
- A hidden or non-obvious policy appeared to override visible workflow intent.
Why this matters
- It causes unnecessary context bloat in exactly the scenarios where subagents are supposed to prevent it.
- It wastes tokens and reduces trust in xhigh orchestration.
- It makes local workflow systems/skills unreliable when visible instructions can be silently overridden by non-obvious policy layers.
Additional note
This report is about product behavior, not just prompt quality. The problem is specifically that explicit user constraints on delegation strategy were not obeyed reliably, and any conflicting higher-priority policy was not made auditable from the normal visible configuration surfaces.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Regarding the main agent doing the work themselves parallel to subagent doing the same work, this was an issue for me as well.
I resolved it by adding an instruction into the harness that the main agent should not be doing the same amount of work because it is redundant. If you want more specifics about how I resolved this, let me know.
As for the actual main issue here where the subagent spawn policy is interfering with the developer level subagent spawn policy, this is something, you can see I made an issue out of this as well. I'm not sure how to resolve this honestly short of having devs modify the system/dev policies. I'm still getting the issues and I have very explicit instructions that the authorization is set explicitly by me, the user. Yet still, the main agent sometimes comments that spawning a subagent is not possible before user authorization.
I've added these to my AGENTS.md, seeing if it resolves anything, basically saying to count X as a user invocation and hopefully the semantics of it gets past the spawn policy.
That might work. I don't get as many issues with this as before due to how much I worked on tweaking my harness, but I still get a comment or two from the main agent about authorization on the spawning of subagents. It usually happens if the thread isn't as clean as 'do this' and you let it rip. It is when the thread has lightly branched, or isn't as clean, or some guidance was added to the main agent during the work, which is like 75% of cases.
Thanks for the bug report. We'll share the feedback with the team responsible for training our codex models. We're tracking this feedback and similar reports so we can improve future models. And thanks for using the
/feedbackcommand. That additional information is useful.I literally have an entire Skill-based and Custom Agents setup centered around this workflow baked into my repo and AGENTS.md, and it still failed to follow it and claimed it was following the system/dev tool instructions, then it rebukes itself and states that obviously user instructions were clear to do the delegation, so those higher-priority instructions do not or should not have mattered. The agent is just confused and cannot follow user instructions.
and the issue is not just context bloat either, it's the core integrity and policy of my entire project based on this delegation policy workflow that requires and mandates independent blind reviews from subagents spawned, because the main agent cannot review itself, it's obviously biased towards no findings. if you simply spawn subagents to independently review the work, it will find a lot of issues the main agent never does. my entire workflow is centered around this for my project, and failing to follow it completely ruins my project, which is what happened. DAYS OF WORK WASTED, AND ANOTHER WEEK OF GOING BACK TO CLEAN UP THE MESS.
thread id: 019d8a20-42a1-7461-b1ad-f93ff7412892