Add Orchestrator/delegate mode such that the main agent is strictly read-only

Resolved 💬 5 comments Opened Apr 16, 2026 by Raylinkh Closed May 31, 2026

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

What variant of Codex are you using?

CLI

What feature would you like to see?

Main agent has the tendency to do everything by itself, especially after context fills up, even explicit instructions and agents.md do not prevent the behaviour.

It is observed that when main-agent delegates effectively, tasks are done better and more efficiently, however, it is not straightforward in codex to enforce this behaviour because subagents inherit permissions from main agent. For claude code, hooks can be used with agent_id to identify subagent, but in codex there is no such arg apparently.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

#16996
#17460
#16771

Powered by Codex Action

CarlChaaya · 4 months ago

I agree this is the better thread to consolidate into.

A few concrete requirements from #18193 that may be useful to fold into this request:

The main value is not just that the orchestrator should delegate more often, but that repos should be able to opt in to treating active workflow/skill routing as sufficient delegation intent.
In that opt-in mode, Codex should be able to read repo-local orchestration rules from sources like AGENTS.md, skills, and .codex/config.toml, then decide that a task is in orchestration territory without the user having to separately say "use subagents".
When that happens, Codex should preferentially select matching project-scoped custom agents from .codex/agents/*.toml rather than falling back to generic workers.
The delegation should remain explainable. For example, the UI/logs should make it clear why a given agent was spawned and which workflow rule caused it.
This should remain opt-in and bounded by repo/runtime limits like thread/depth caps.

So from my perspective, the missing behavior is something like:

Repo opts into delegation-aware orchestration.
Active skill/workflow routes task to orchestrate.
Main agent stays in orchestrator mode instead of absorbing the work.
Matching custom agents are spawned automatically.
The reason for the delegation is visible.

Closing #18193 in favor of this issue.

dylanbuchi · 4 months ago

Adding a narrower use case that seems worth preserving under this broader feature request.

I use Codex in repo/workflow setups that rely heavily on bounded subagent use. The current requirement that I restate delegation permission in the prompt (for example: "use subagents when needed") is a real UX tax in those environments.

What I want is not global default-on delegation. I want an explicit opt-in setting/profile/repo-level mode that allows bounded autonomous delegation for users and workflows that intentionally want it.

A shape like this would cover my use case:

explicit: current behavior
workflow: allow delegation when repo/workflow instructions explicitly route the task to orchestration
auto: allow bounded sidecar delegation when useful

Important constraints:

conservative depth/fanout limits
no duplicate parent-thread work after delegation
clear visibility in UI/history/logs about when Codex delegated and why
conservative handling around approvals and security-sensitive actions

So from my side, this broader orchestrator/delegate request is the right umbrella issue, but I wanted to add that a first-class opt-in delegation policy/setting would already solve a lot of the day-to-day friction for subagent-heavy workflows.

etraut-openai contributor · 2 months ago

This feature request hasn't received enough upvotes, so I'm closing.

Raylinkh · 2 months ago

https://github.com/Raylinkh/delegate-mode implemented a workaround here if anyone needs it