How to Migrate From Amp to Codex Without Losing Context (2026)

Your AGENTS.md content transfers cleanly. Both tools read plain Markdown with no required structure. Amp's docs describe looking in AGENTS.md files "for guidance on codebase structure, build/test commands, and conventions"; Codex's say it "reads AGENTS.md files before doing any work." Nothing about the prose needs to change.

Root-level guidance transfers. A single AGENTS.md at the repository root is the one configuration both tools handle identically.

Nested AGENTS.md files transfer, with different timing. Amp includes "subtree AGENTS.md files … when the agent reads a file in the subtree" — lazily, triggered by file access. Codex assembles its chain up front: it "builds an instruction chain when it starts (once per run; in the TUI this usually means once per launched session)," walking from the project root down to your working directory. Same files, different moment, and in Codex's case only the directories on the path from root to cwd.

Guidance above your repository does not transfer. This is the first real break. Amp always includes AGENTS.md files in "the current working directory (or editor workspace roots) and parent directories (up to $HOME)," plus $HOME/.config/amp/AGENTS.md, $HOME/.config/AGENTS.md, and system-wide files. Codex's project scope starts at the project root — "typically the Git root" — and walks down. Anything you kept in a parent folder above the repo is simply not on Codex's path. Codex has a global scope, but it is one specific location: AGENTS.override.md or AGENTS.md in your Codex home directory, and it "uses only the first non-empty file at this level."

Your CLAUDE.md fallback does not transfer by default. Amp's rule is explicit: "If no AGENTS.md exists in a directory, but a file named AGENT.md (without an S) or CLAUDE.md does exist, that file will be included." Codex has no such implicit fallback. It checks AGENTS.override.md, then AGENTS.md, then whatever you list in project_doc_fallback_filenames, and the docs are blunt about the rest: "Filenames not on this list are ignored for instruction discovery." If a directory in your repo has been running on a CLAUDE.md this whole time, moving to Codex turns it off silently.

Glob-scoped guidance does not transfer. This is the biggest gap, and Codex's documented scoping mechanism works on a different axis entirely. Amp lets a root AGENTS.md @-mention other files, and those mentioned files can carry globs in YAML front matter: "Mentioned files with globs will only be included if Amp has read a file matching any of the globs," with globs "implicitly prefixed with **/ unless they start with ../ or ./." That gives you conditional, always-flat guidance — docs/typescript-conventions.md activates when a TypeScript file is read, and stays out of the way otherwise. If you have built this out, we described the pattern in scoping Amp's instructions to the files they apply to.

Codex's documented scoping mechanism is directory nesting. There is no documented counterpart to glob-conditional inclusion. So each of those scoped files has to become either a nested AGENTS.md in the directory it governs, or unconditional text in a parent file — and unconditional text counts against the cap, which is the next problem.

Your AGENTS.md size may now matter. Amp's agent-file documentation does not specify a combined size limit. Codex's does: it "skips empty files and stops adding files once the combined size reaches the limit defined by project_doc_max_bytes (32 KiB by default)." The failure is not an error; it is guidance that stops being included. Collapsing a set of glob-scoped files into one always-on file is exactly how a comfortable setup crosses that line.

What Amp does not have, and Codex does. Amp's documented persistence mechanism is the AGENTS.md files you write, plus threads. There is no documented counterpart in Amp to a store that writes itself from prior sessions. Codex has one: "Memories let ChatGPT and Codex carry useful context from earlier work into future work." It is worth being precise about what that is before you lean on it, which the next section covers.

Step 1: Rebuild the discovery tree for a downward walk

Run agents-md list from Amp's command palette first. That gives you the actual set of files Amp is using right now, which is almost always larger than the set you remember writing.

Then sort that list into four groups.

Files at or below your repository root, in directories on the path you normally work from, need no change. Codex will find them.

Files in parent directories above the repo need a decision. If the content is personal — device-specific commands, preferences you are testing — it belongs in ~/.codex/AGENTS.md, Codex's global scope. If it is project content that happened to live above the repo, move it into the repo. It will not be discovered where it is.

CLAUDE.md and AGENT.md files that Amp has been silently promoting need to be made explicit. Either rename them to AGENTS.md, which is the cleaner outcome and the one we walk through in migrating CLAUDE.md to AGENTS.md, or add them to project_doc_fallback_filenames in ~/.codex/config.toml so Codex treats them as instruction files. Renaming is better if you have left Amp; the fallback list is better if some teammates are still on Amp and expect the old names.

Glob-scoped @-mentioned files need to be relocated to the directories they govern. A file whose globs are src/components/** and **/*.tsx becomes src/components/AGENTS.md. One whose globs span unrelated trees has to be split, or promoted to always-on and budgeted against the cap.

Two Codex behaviors to hold in mind while you do this. Only one file per directory is used — "Codex includes at most one file per directory" — and AGENTS.override.md beats AGENTS.md in the same directory, with the sibling ignored entirely. And merge order is root-down: "Files closer to your current directory override earlier guidance because they appear later in the combined prompt." So specificity comes from depth, not from a rule type.

Verify by starting Codex from a nested directory and asking it to list the instruction sources it loaded. If a file you expected is missing, the usual causes are that it is above the project root, that a sibling override suppressed it, or that the chain hit the byte cap. Related discovery failures are covered in why Codex skips your AGENTS.md rules, and the same discovery model applies if you are arriving from Copilot rather than Amp.

Step 2: Decide what Codex Memories is allowed to be responsible for

Codex's memory layer is off by default; you enable it in Settings > Personalization. Once on, "Codex can turn useful context from eligible prior chats into local memory files." It "skips active or short-lived sessions, redacts secrets from generated memory fields, and updates memories in the background instead of immediately at the end of every chat." The files live under ~/.codex/memories/ and "include summaries, durable entries, recent inputs, and supporting evidence from prior chats." Per chat, /memories controls whether the current conversation can read existing memories or feed future ones, and "chat-level choices don't change your global memory settings."

Read OpenAI's own guidance before deciding how much weight to put on this: "Keep required team guidance in AGENTS.md or checked-in documentation. Treat memories as a helpful recall layer, not as the only source for rules that must always apply."

That is the correct boundary and it is worth restating in your own terms. Codex Memories is a local, per-installation, generated recall layer. The docs say to "treat these files as generated state" and not to "rely on editing them by hand as your primary control surface." It is not shared with teammates, it is tied to a Codex home directory, and generation can be skipped when you are near a rate limit. It is genuinely useful for reducing repetition on your own machine. It is not where a team decision goes.

Which leaves the same gap you had on Amp, now with a clearer shape: the things your team established while working — why you moved off the streaming parser, which two fixes already failed on the flaky test, the customer-mandated naming — belong in neither an instruction file nor a per-laptop generated store. It is the same gap that makes sharing context between sessions an unsolved problem in every one of these tools.

The reason this migration is fiddly is that both tools are solving "what should the agent always know," and neither is solving "what did we learn." Instruction files are re-sent every run by design. A generated local store is per machine by design. Team knowledge is neither.

MemoryLake sits outside both. It holds the discovered facts, exposes them over MCP and an API, and does not care whether the client this week is Amp, Codex, or something you have not adopted yet. That also makes the next migration boring, which is the actual goal.

Step 1: Create an API key

Generate a key and make your first request in about thirty seconds. One key, readable from every surface your team uses, is what keeps the knowledge from becoming a property of one editor's config directory.

Step 2: Upload your first memories

Drop in the documents, images, and files that already carry your established decisions — architecture notes, the incident writeup behind the current retry policy, the design review nobody wants to repeat. Start with what you are tired of re-explaining.

Step 3: Connect your AI & agents

Give Claude, Codex, OpenClaw, and other agents access over MCP or the API. In practice, read the relevant memories at the start of a task and write back the corrections you make during it, so the correction outlives the session it happened in.

The migration stops being risky. Once your discovery tree is rebuilt and your team knowledge is outside both tools, the only thing a future tool change touches is instruction file syntax — an afternoon, not a rediscovery project.

Your AGENTS.md files get smaller and better. Most bloated instruction files are bloated because they accumulated discovered facts that had nowhere else to go. Moving those out puts you comfortably under the 32 KiB cap and, more usefully, makes the remaining content actually about how to work in the repository.

Codex Memories becomes safe to enable. Once required rules live in checked-in files and team knowledge lives in a shared store, a local recall layer is a pure convenience with no load-bearing role. That is exactly the posture OpenAI's docs recommend.

And the things that used to be tribal stop being tribal. A new engineer's Codex reads the same established decisions as everyone else's on the first task, instead of after three months of absorbing them by being corrected.

Rebuild the tree before you trust it. Start Codex from your deepest working directory and ask what it loaded. Depth changes the answer, which is not true on Amp.

Prefer renaming over the fallback list. project_doc_fallback_filenames works, but it is a local config file. A renamed AGENTS.md is in the repo and works for everyone.

Put overrides close to the work. Codex's own advice: "place overrides as close to specialized work as possible," since the walk stops at your current directory.

Watch the cap when you flatten globs. Every glob-scoped Amp file that becomes always-on text is now competing for 32 KiB. Nesting is cheaper than raising the limit.

Keep ## Code Review Rules scoped. Codex reads that section from the AGENTS.md closest to the code it governs, so root-level checks go at the root and service-specific ones in nested files.

Do not put secrets in memories. Codex redacts secrets from generated fields, and its docs still tell you to review the files before sharing your Codex home directory. Both are true; treat the redaction as a backstop, not a permission.

Amp and Codex read the same file format and disagree about almost everything else regarding where to look for it. Amp searches upward and includes generously; Codex assembles one chain downward, takes one file per directory, and stops at a byte cap. Neither approach is wrong, and the tools document their own behavior clearly enough that the migration is mechanical once you stop assuming file compatibility means behavioral compatibility.

The part that is not mechanical is the part neither tool claims. Codex's own documentation draws the line for you — memories are "a helpful recall layer, not … the only source for rules that must always apply" — and the corollary is that a third category exists: what your team figured out, which is too specific for an instruction file and too shared for a per-laptop store. Put that somewhere both tools can read, rebuild the discovery tree for a downward walk, and the move takes an afternoon and stays done.