Codex Desktop loads global AGENTS.md but stale memory overrides its explicit rule
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop package 26.814.5167.0; session metadata reports bundled CLI 0.148.0-alpha.15.
What subscription do you have?
Not included in this public report.
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
Codex Desktop loaded both the global ~/.codex/AGENTS.md and the repository AGENTS.md into the task context, but the agent ignored a distinctive current global rule and instead followed stale validation-gate guidance recovered from persistent memory.
The global rule explicitly defined this sequence for validation-gate requests:
- Ponytail Review
- Ponytail cuts
- Clean Code Guard
- Test Guard
When asked to apply the validation gates, the agent instead invoked an unrelated security workflow based on stale memory. It only discovered and followed the current global rule after the user challenged the behavior.
This initially looked like an AGENTS.md discovery failure. Inspection of the task rollout disproved that: the first user-context item and world state contain both the distinctive global rule and the repository instructions. The problem is instruction precedence/compliance: stale memory was treated as more authoritative than the current, explicitly loaded global AGENTS.md.
What steps can reproduce the bug?
- Put a distinctive workflow rule in
~/.codex/AGENTS.md. - Have older persistent memory contain a conflicting workflow for the same request.
- Open a Codex Desktop task in a repository that also has a repository
AGENTS.md. - Ask Codex to execute the workflow named by the global rule.
- Observe that Codex follows the stale memory workflow instead of the currently loaded global rule.
- Inspect the task rollout under
~/.codex/sessions: confirm that the global and repositoryAGENTS.mdcontents were present at task start.
Observed session ID: 01a01512-ddef-77c3-b0cd-8c5610997742.
The local rollout contains both instruction sources in the initial context; no private transcript or workspace content is attached to this public issue.
What is the expected behavior?
A current, successfully loaded AGENTS.md rule should win over conflicting stale memory for repository work. Persistent memory should provide historical context, not silently override explicit current operating instructions.
If these sources are intentionally assigned different prompt priorities, Codex Desktop should ensure stale memory cannot become an authoritative workflow policy that defeats the current AGENTS.md chain.
Additional information
This is distinct from a pure discovery failure such as #18189: the rollout proves the global file was loaded.
It is related to instruction-enforcement concerns reported in #19369, but this reproduction specifically shows a current global rule losing to stale persistent memory in Codex Desktop.
Official documentation says Codex builds an instruction chain from global and project AGENTS.md files before work begins:
https://developers.openai.com/codex/guides/agents-md
Impact: users can receive false confidence that current repository/global controls are active while older remembered workflows silently drive tool selection and execution.
1 Comment
The part worth separating out is that this is not a discovery failure. You already proved the current rule was loaded, both the global one and the repo one sat in the first context item, and the agent still reached for a stale rule instead. That is a precedence bug, not a missing file.
I have hit a version of this building memory for agents, where an old fact and a corrected fact both stay independently retrievable unless the store treats the correction as replacing the old one rather than sitting next to it. If persistent memory here keeps both the old validation-gate sequence and the new one as separate entries, similarity retrieval has no reason to prefer the newer one, since they are both about the same topic and the old one might even be a better semantic match to the query.
The fix that worked for me was making a correction explicitly supersede what it replaces rather than just appending, so the old entry stops being retrievable as current fact once something newer covers the same ground, while still being kept around for audit rather than deleted outright.
Worth checking whether the stale rule is sitting in memory as an independent entry never marked superseded by the newer one you set in AGENTS.md. If it is a genuine precedence bug elsewhere in the stack that is a different fix, but it is worth ruling out first since it is checkable. Repo is https://github.com/samvallad33/vestige if it helps to compare notes on how the supersede path is structured.