Centralize and Support High-Level Developer Instructions

I think the most important design constraint here is: please do not solve this by physically rewriting CODEX_HOME/AGENTS.md or repo AGENTS.md files as the canonical global-developer layer.

That works as a workaround, but it has three bad side effects:

• it contaminates working copies and can leak into git state
• it makes cloud / web / local behavior diverge based on bootstrap timing
• it gives users no inspectable answer to "which instruction won?"

The cleaner model is an explicit instruction stack with provenance, something like:

1. platform / org
2. user
3. codex-developer-global
4. environment
5. project AGENTS.md
6. subfolder AGENTS.md

Then merge those layers in one place, with the same precedence rules everywhere, and expose the active stack in a debug surface (/status, session metadata, or similar) so users can see both content source and effective order.

That would solve two problems at once:

• consistent behavior across Web, CLI, IDE, and cloud sessions
• much better debuggability when instructions conflict

If the product team is not ready to ship a new global layer yet, the docs ask in this issue still feels valid. A documented "virtual layer" model and an inspectable precedence story would already be a big improvement over today's copy-sync folklore.

@pandego Sincere thanks for your well-articulated and insightful comments.

I believe your suggestion for effective stack debugging is a valuable separate request.

I absolutely do not want to expand the scope of this request to a point where it's impossible to implement because of far-reaching considerations. But your notes remind me that even in ChatGPT, debuggability of instructions is challenge. I take a lot of care to tune Project instructions and GPT instructions to eliminate assistant tensions. While the assistant is correctly vague about tensions with System instructions, it's also sometimes difficult to identify where tensions arise below that tier - which relates to your notes about exposing the active stack clearly for debugging.

About CODEX_HOME/AGENTS.md, unless that location is somehow included in a repo, I don't see how it can leak into git state. I think the environment variable is only available by default in Codex Web, and it's outside of the default /workspace path. Someone would need to take awkward steps to make it a part of the git pipeline.
I tried to use ~/.codex/AGENTS.md (Codex Web user is 'root') but that was also deleted after enviroment setup (and Web doesn't use that folder anyway). It would be helpful to know how or why the environment is rejecting write operations performed by the Web environment setup. It seems like a fault in itself.

This also reminds me that (to my knowledge) there's no ability in the API to activate higher-level set of instructions from the API key account holder - all instructions must be provided in every thread, which can be a source of network traffic bloat. Even in this case (separate ticket!) I can envision Instructions per-key, for all API operations in a group of keys, or for all API operations for an account.

Summary

I'm just emphasizing that these products have evolved in isolation from one another, and features within the products have also evolved in isolation from one another. The hierarchy of instructions to which we all refer hasn't adapted to the addition of new products or their features. I believe that hierarchy model needs to be a guide, not a fixed statement, with variants clearly defined for each product and feature - configurable and debuggable by developers.

Imagine a single dashboard where you specify your environment, you're provided with all possible blocks of instructions that can be invoked for that environment, and then when you open that environment you can select from those blocks for the current context. That's a determinate configuration model that eliminates having instructions in a bunch of different places and UIs. The hierarchy still applies, AGENTS and Skills don't change because they are processed below the tier described here.

That's not what I'm asking for with this ticket. But I'd be happy to create a new ticket that obsoletes this one if it's approved and processed by the company.

EDIT:
I should also mention that support for common instructions implies that new instructions will be applied to existing environments. That means current environments change, which isn't good for developers. All such changes need to be opt-in configurable. That is, Codex-Global instructions must not be applied to a Codex session until the developer ensures that they've removed local instructions that were required for lack of the higher tier. Otherwise there will be duplication, tensions, and lower-quality model responses.

This feature request hasn't received enough upvotes, so it is being closed automatically. If you still feel this feature is needed, please open a new feature request with an updated title and description.