Pathruleこのページは英語でのみご覧いただけます。
How to Give Codex Persistent Project Memory
Codex can remember locally.
The practical question is which knowledge should stay personal, which belongs to the team, and how the same rule reaches the next agent.
結論
Codex has opt-in local memories generated from eligible past chats, stored under `~/.codex/memories/`. It also reads global and project `AGENTS.md` instructions. Local memories help one Codex installation; committed instruction files help a repository. Pathrule supplies shared, task-selected knowledge to Codex and other agents, with rule enforcement where the integration has a blocking hook.
この記事の内容
- Codex local memories are off by default. They are stored under ~/.codex/memories/ and are not a team knowledge store.
- Codex discovers global and nested AGENTS.md files, with nearer project instructions taking precedence within its documented size limit.
- Pathrule's distinction is shared knowledge selected for the current task across Codex and other agents, typed requirements, and enforcement where a blocking hook is available.
- On a pinned 12-task, 24-run compliance test, functional success was 12/12 in both conditions; convention compliance was 3/12 without Pathrule and 12/12 with it. This was a Claude Code test, not a Codex memory comparison.
導入前と導入後
| 項目 | One AGENTS.md at the root | Knowledge supplied per run |
|---|---|---|
Working in services/billing | The whole file ships, including the mobile and data-pipeline rules | The slice attached to that path ships |
| A convention learned yesterday by a teammate | Local memory stays with that Codex installation; shared files require a commit | Shared workspace knowledge reaches supported agents without a repository commit |
| A constraint that must not be violated | A line in a document the model weighs | A rule with a scope and an enforcement level |
| Switching to a different agent next quarter | Check whether the next tool reads the same instruction file | The knowledge is stored outside both tools |
Two ways Codex carries knowledge forward
Codex memories are a real, local persistence feature. They are off by default, can be enabled in the desktop app or with [features] memories = true in config.toml, and live under ~/.codex/memories/. Codex generates them from eligible past chats, so a recent correction may take time to appear and some chats are skipped. /memories lets a CLI user inspect or manage them.
AGENTS.md instructions are the other path. Codex reads global instructions and then project files from the repository root toward the working directory. A nearer file can refine guidance for one part of the tree. These files can be committed and reviewed by the team.
The two mechanisms serve different jobs. Local memories can help your own Codex sessions. A committed AGENTS.md records explicit project instructions. OpenAI recommends keeping required team guidance in instruction files rather than relying on generated local memories alone.
Where local memory stops
Codex's local store is useful, but it is local to Codex. A teammate using Claude Code does not receive a memory generated in your Codex installation, and a local memory is not a reviewed workspace rule. That is a sharing boundary, not an absence of memory.
The stronger question is whether a project decision reaches the next person and the next agent at the moment it matters. For example, a rule for services/billing should reach a Codex task there and a Claude Code task there, while a mobile-only convention should stay out of both prompts. A strict constraint also needs a blocking path where the client supports one.
Answer one: write more into AGENTS.md
The obvious first move is to put more in the root file. It works, and for a small repository with a short list of conventions it is the correct answer, which is worth saying because the rest of this article is about cases where it stops being correct.
A short root file works well. As it grows, its guidance applies broadly even when the task is narrow. Put project-wide constants here and move area-specific guidance into nested files.
Answer two: nest AGENTS.md files per directory
This is the underused one, and it follows directly from the concatenation rule. An AGENTS.md in services/billing/ is only picked up when you are working at or below that directory, and because it lands later in the chain it overrides the root file. That gives you real scoping with no tooling at all.
For a team using AGENTS.md-aware tools, this may be enough. The remaining limits are operational: files move at commit and pull speed, everything in scope is text, and a requirement is still a sentence the model may weigh against other instructions. Other agents may read AGENTS.md too, but support and precedence differ by product. For example, Claude Code reads AGENTS.md directly only under documented conditions.
The comparison between the file standard itself and a routed layer is worked through in AGENTS.md vs Pathrule. The short version is that they are complementary: keep a short AGENTS.md for repository-wide constants, and put the long tail somewhere that can scope it.
Answer three: share task-relevant knowledge across agents
Pathrule stores workspace memories, rules and skills by path and selects the relevant slice for each task. The same workspace entry can reach Codex, Claude Code and other supported agents through their Pathrule integrations. A strict rule can block a matching action where the integration exposes a blocking hook; context-only integrations deliver guidance but cannot enforce it.
This is measurable as an outcome, not a claim that other agents forget. In our 12-task, 24-run compliance grid, one pinned Claude Code model completed all 12 tasks functionally in both conditions. It followed hidden project conventions in 3/12 runs without Pathrule and 12/12 with Pathrule; violations fell from eight to zero. The test did not compare Codex local memory or prove the same lift for every agent.
What to do first
Print the chain before you change anything. Knowing which files Codex actually picks up from where you normally work answers most confusion in one step, and it is common to find a file that is never in scope for the directory the work happens in.
Then split the root file. Move anything that is true of one area into an AGENTS.md in that area, and keep the root for things that are true everywhere. That single change usually shortens the root file enough to make it worth reading again.
Use local Codex memories for your own recurring context and explicit AGENTS.md files for reviewed project instructions. Add a shared layer when knowledge must reach teammates and different agents, be selected for each task, or be enforced at a supported hook. Check the measured results and their limits before treating any outcome claim as universal.