Allow subagents to override inherited personal/custom instructions

Open 💬 3 comments Opened Jun 6, 2026 by DaemoncheG
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex subagents appear to inherit personal custom instructions / global AGENTS.md guidance by default. That inheritance is useful for safety and consistency, but there does not seem to be a clear way to scope or override broad personal instructions for specialized subagent roles.

This creates ambiguity when personal/custom instructions contain parent-level workflow rules or Definitions of Done.

Example personal/project instructions:

  • Use risk-first behavior.
  • Prefer mature OSS/library baselines before building custom solutions.
  • Keep project docs under docs/aidk/**.
  • Do not consider the task complete until relevant project docs are updated.
  • Show a short plan before nontrivial changes.
  • Do not change stable project profiles without confirmation.

These are reasonable rules for the main/orchestrator agent. But when Codex spawns a specialized subagent, especially an explorer, read-only reviewer, or narrowly scoped worker, the same inherited instructions may imply that the subagent should update docs, perform parent-level closure checks, or follow workflow obligations that were intended for the parent agent.

For example, a subagent prompt might explicitly say:

You are an explorer. Read only. Do not edit files. Report findings to the parent agent.

But inherited personal/project instructions may still include parent-level obligations like updating docs before the task is complete. The intended behavior in that role is not to edit docs, but to report any required documentation follow-up to the parent agent.

Expected behavior

Codex should keep inheriting safety-critical settings such as sandbox policy, approvals, and security constraints. However, subagents should have a first-class or documented way to override or scope inherited personal/custom instructions.

Possible approaches:

  1. Add a spawn_agent option to control inherited personalization, for example:
{
  "inherit_personal_instructions": false,
  "inherit_project_instructions": true
}
  1. Add custom agent TOML controls, for example:
name = "explorer"
description = "Read-only codebase exploration agent."
developer_instructions = "Read only. Report findings to the parent agent."

inherit_personal_instructions = false
instruction_scope = "explorer_read_only"
  1. Support instruction scoping in personal/custom instructions or AGENTS.md, for example:
[applies_to: parent_only]
The parent task is not complete until relevant project docs are updated.

[applies_to: all_agents]
Follow sandbox, security, and repository constraints.

[applies_to: read_only_subagents]
Report required doc updates to the parent instead of editing docs.
  1. At minimum, document the inheritance boundary clearly and recommend safe patterns for parent-only DoD rules.

Why this matters

Without instruction scoping, users have to choose between two weak options:

  • Keep global personalization extremely generic, losing useful workflow guidance.
  • Keep useful workflow guidance globally and risk specialized subagents misapplying parent-level rules.

The current behavior is especially confusing because Codex settings expose Personalization as a normal place for custom instructions, and the docs say those instructions update personal AGENTS.md. Subagents then behave like spawned sessions that inherit configuration, but there is no obvious mechanism to say which inherited instructions are meant for the parent/orchestrator only.

The core request is not to disable inheritance entirely. It is to let users and custom agents separate:

  • safety/config inheritance
  • personal style/default behavior
  • project conventions
  • parent/orchestrator-only workflow obligations
  • worker-only instructions
  • explorer/read-only instructions

Related issues

This seems related but not identical to:

  • #16996, where repo/workflow instructions conflict with subagent spawn policy.
  • #13491, where forked workers inherit parent intent and misinterpret it as active instruction.

This issue is specifically about missing scoping/override controls for inherited personal/custom instructions in subagents, even when fork_context is false and the subagent prompt itself is narrow.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25472

Powered by Codex Action

DaemoncheG · 2 months ago

I reviewed the duplicate suggestion for #25472.

It looks related, but I do not think this is the same issue.

#25472 is about Goal Mode/session state leaking into subagents: a subagent picked up the parent thread goal and started behaving like the main thread.

This issue is about a broader instruction-scoping problem: inherited personal/custom instructions and global AGENTS.md guidance can contain parent/orchestrator-level workflow obligations, and there does not appear to be a way for a spawned subagent or custom agent to opt out of, reinterpret, or scope those inherited instructions.

The specific concern here should still apply even when:

  • Goal Mode is not active.
  • fork_context is false.
  • The subagent receives a narrow role prompt such as read-only explorer/reviewer.
  • The problematic inherited instruction comes from Personalization / personal AGENTS.md, not from the parent conversation history.

So I think #25472 is an example of a related instruction-boundary/session-boundary failure, but this issue is specifically requesting override/scoping controls for inherited personal/custom instructions in subagents.

Necmttn · 2 months ago

Subagent instructions would be easier to reason about as typed layers.

Separate safety, account-level preference, project policy, parent-orchestrator guidance, and worker-local instructions. Each child session can show which layers were inherited, overridden, or masked, with hashes/provenance. That lets specialized agents opt out of parent workflow rules without dropping safety or project constraints.

---

_Generated with ax._