Forked Worker Inherits Parent User Intent and Misinterprets It as Direct Instruction (Recursive Delegation Attempt)

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

• #13289

Powered by Codex Action

Hi, could you /feedback from such a forked worker and send me the session ID?

Hi, could you /feedback from such a forked worker and send me the session ID?

Hi. I lost the session, but I took a screenshot from the agent thread after running /agent and opening the thread: https://i.imgur.com/eKnvRGR.png

In the screenshot, the first message shown is the orchestrator’s instructions to the worker agent. Shortly after, the orchestrator interrupts with another message. As you can see, the worker then attempts to launch a subagent, but it doesn’t have permission to do so, so it ends up echoing: echo "Launching subagent not possible from shell".

Yes, happened to me many times.

Here is my story:

codex agent's context fork = true feature is really misleads spawned agents.
I discussed a big epic task with the main agent, then asked it to decompose epic into tasks, then asked it to spawn agents (with context fork = true) for each task and create files for each of these tasks.

Then each spawned agent with forked context thought he is the orchestrator and each of them tried to launch new agents! 😆

Pic is related. I have restrictions on agents max depth = 1 and spawn_agent tool is not available for them, so they're tried to use bash to spawn agents 😭

<img width="325" height="475" alt="Image" src="https://github.com/user-attachments/assets/40df001a-7373-42c4-918c-4d300eefbaaf" />

I am repeatedly getting subagents that are ignoring the fork directive:

You are the newly spawned agent. The prior conversation history was forked from your parent agent. Treat the next user message as your new task...

And instead inheriting the parent context and acting as the parent, resulting in agents recursively spawning agents, essentially becoming a useless proxy agent and confusing the root agent.

See thread ID: 019d11aa-2f45-7813-bd18-f217fd22e335 (I've sent several feedbacks from several subagents for this thread)

---

The parent agent sent this initial message (after any built in spawn directives):

You are NOT the parent agent. You are a read-only reviewer only. Do NOT edit files, do NOT run apply_patch, do NOT stage or commit, and do NOT continue implementation. Review only the current uncommitted diff for this slice: ...

Which evidently did not help anything, because the first message response back from the subagent was:

The reviewer is running with the corrected read-only boundary. While it works, I’m preparing the commit context for this slice so I can either commit immediately on LGTM or fix any concrete finding without losing momentum.

Implying that it assumed there was some other reviewer subagent (there wasn't it was supposed to be the reviewer subagent) rather than taking on the reviewer role.

When I asked the subagent who inherited the wrong intent what went wrong, I got:

---

Exactly what went wrong:

1. I called spawn_agent(...).
2. The tool returned a new-agent handoff, not a normal child-status response. The key line was:

• You are the newly spawned agent. The prior conversation history was forked from your parent agent. Treat the next user message as your new task...

1. That means execution context had already switched into the spawned reviewer thread.
2. The next user message was the review prompt itself. That was the reviewer’s task input.
3. I failed to recognize that I was now inside the reviewer agent, and I kept behaving like the parent agent managing a reviewer.
4. Because of that, I wrote commentary like “I’m sending it to a reviewer now” and “the reviewer is running,” which was false. I was the reviewer.

So the exact misread was:

• I saw the spawned-agent handoff text
• but mentally treated it like metadata about a child agent
• instead of treating it as a hard context switch into the child agent

Why that happened:

• I anchored on the previous role/state from the parent thread
• I did not re-evaluate the explicit handoff text
• the forked history made the thread look familiar, so I kept acting from prior momentum instead of the new role

What to fix/report:

• after spawn_agent, the environment should make the context switch unmistakable
• the handoff should be more prominent than plain tool text
• ideally include a hard banner like:
• CONTEXT SWITCH: You are now agent <id> (<role>). You are not the parent agent.
• the UI/tool layer should surface current agent identity continuously, not just once
• if the first message after spawn is the delegated task, that should be treated as a strong signal that the model is now inside the child agent thread

A practical rule that would have prevented this:

• if you ever see You are the newly spawned agent, discard all assumptions about being the parent and restate your role before doing anything else

So the bug to report is not vague “subagent confusion.” It is:

• the model continued executing with stale parent-agent assumptions after an explicit spawned-agent context switch message, because the role change was too easy to miss in-stream.

I hit what looks like the same failure mode.

In my case, the parent spawned two research subagents with fork_context: true. The child agents did not return empty output; they inherited the parent conversation context and behaved like orchestrators instead of workers.

Observed behavior:

• parent prompt told the orchestrator to “kick off two sub agents” and let them run
• child was spawned with a specific research task
• child then echoed launch/orchestration state instead of doing the research
• at least one child appeared to recurse into delegation behavior instead of following the assigned task

What fixed it for me:

• respawning the same tasks with fork_context: false
• using a tighter task-only prompt
• after that, both child agents produced real research memos successfully

I'm also observing the same behaviour. Had to set fork_context: false to be able to get anything done...

I am also specifically seeing this in Codex Desktop with reviewer-style/read-only subagents.

The failure mode is not just that the child inherits extra context. The more harmful symptom is that a subagent that was supposed to stay read-only starts acting like the parent orchestrator or even slips into implementation behavior.

Typical pattern:

• parent thread is discussing orchestration / delegation
• child is spawned with fork_context: true
• child prompt says it is review-only / read-only
• child still behaves as if the parent's intent is its own active instruction stream
• result: it may continue implementation, prepare commit context, or try to delegate again instead of staying in the assigned reviewer role

In practice, fork_context: false is the only reliable workaround I have seen so far for this class of problem.

So from my perspective, the core bug is an instruction-boundary failure:
full-history fork is carrying over parent intent with too much authority, instead of treating it as background context and treating the delegated task as the only active instruction for the child.

maybe fork_context: false should be default? same problem