CLAUDE.md Equivalent for Codex: Move Instructions Safely

The usual CLAUDE.md equivalent for Codex is AGENTS.md: a Markdown file containing the repository guidance Codex should read before working. Move shared instructions into that file, then review anything tied to Claude’s commands, settings, or file-loading behavior instead of simply renaming the old file.

The instruction file explains how to work in the codebase. Tools like fenbs keep changing decisions, tasks, and progress available to both assistants, so a model switch also preserves where the work stopped. These are complementary records: one describes the repository, while the other describes its active work.

Where should Codex instructions live?

Place shared project guidance in an AGENTS.md at the repository root. OpenAI’s official instructions guide↗ (opens in a new tab) describes global guidance plus project files collected from the root toward the working directory. More specific files can refine the root instructions. Codex also supports override files and configured fallback names, so inspect an existing setup before adding another instruction source.

Start with the root file because it gives a new contributor the essentials. Put rules for a specialized area near that area when appropriate. Avoid copying the whole root document into every package: repeated text creates several places that must stay consistent.

A useful root file names the package manager, the main folders, the checks expected for changes, and boundaries such as “ask before deploying.” It should help someone perform the next task without guessing. The broader Claude Code and Codex comparison covers choosing between the tools.

How do you move an existing instruction file?

1. Read the current CLAUDE.md and every file it depends on. List the rules that apply to any assistant, the Claude-specific instructions, and the notes that describe temporary work.
2. Create or update the root AGENTS.md with the shared rules. Verify every command against the repository scripts and documentation before preserving it.
3. Rewrite tool-specific lines as outcomes when possible. “Summarize the proposed changes before editing” travels better than an instruction to invoke one tool’s named mode.
4. Keep tool configuration in the relevant configuration files. Do not assume moving prose transfers permissions, connections, credentials, or installed extensions.
5. Start a fresh Codex session in the intended directory. Ask it to list the instruction sources and explain the checks and boundaries for a small task.

Treat this as a review of meaning. An old instruction may name a deleted folder or a command that no longer runs. Carrying it into a second tool makes the error more durable, so use the migration to remove outdated guidance and clarify ambiguous requirements.

What does a small shared file look like?

Write concrete instructions that a person could also follow. The example below is illustrative: replace every command and path with the real ones for your repository. Keep a requirement only when you know why it belongs there.

# Project guidance

## Start here
- Read README.md for the project purpose and local setup.
- Use the package manager declared in package.json.
- Read instructions in the area you are changing.

## Make changes
- Keep the change within the requested task.
- Preserve existing public behavior unless the task changes it.
- Ask before adding a production dependency or deploying.

## Verify and report
- Run the relevant checks documented in package.json.
- State what changed, what was checked, and what remains uncertain.
- Do not describe an unrun check as passed.

Prefer “run the checkout test when changing payment behavior” to “test thoroughly.” The first instruction identifies a trigger and an action. Similarly, explain which files contain the domain rules rather than asking the assistant to remember a long duplicate description of those rules.

For more writing patterns, see the existing CLAUDE.md examples. Adapt their intent to your repository rather than copying commands from an unrelated project.

Can Claude Code and Codex share the same rules?

Yes, a shared AGENTS.md can hold instructions useful to both. Anthropic’s memory documentation↗ (opens in a new tab) explains that current Claude Code can read it natively, subject to its instruction-file selection rules. An existing CLAUDE.md can affect that selection, and a Claude import can include the shared file where needed.

Check both tools after changing the layout. Do not assume that a line of import syntax recognized by one tool has the same meaning to the other. The separate guide to Claude Code reading AGENTS.md covers the Claude-specific cases in detail.

Choose one place to edit each shared rule. A short tool-specific addition can explain a real difference, but a second full copy of the rules invites drift. When a reviewer changes a testing requirement, they should not have to remember another nearly identical file.

How do you verify the migration before real work?

Begin with a read-only request. Ask Codex which files supplied its instructions, which package manager it will use, what checks the task requires, and which actions require a person’s approval. Compare its answer with the files instead of accepting a general assurance that it understands.

Repeat the check from a directory with specialized guidance. If the answer changes unexpectedly, inspect the applicable files and overrides. Restart after editing instruction sources so you test the next session’s starting conditions, rather than relying on a conversation that already discussed the rules.

Then try one small reversible task and inspect the result. Did it use the correct command, respect the scope, and report the actual check? A correct readback is useful evidence of loading; correct behavior on a real task is the next check. Instructions still need review and maintenance.

How to do this with fenbs

1. Create a free account and add the project whose work moves between Claude Code and Codex.
2. Record people’s standing decisions in Decisions and rules. Add reusable task instructions to Skills and prompts, with enough context to know when to use them.
3. Connect both supported tools from Integrations using browser sign-in. Ask each assistant to read the project context before working.
4. Save progress on the tasks and Where we left off before switching tools. Ask the next assistant to explain the current task and remaining checks.

fenbs is free for one person, with no credit card. It is not the right fit if you only need a static repository instruction file. It helps when prompts, decisions, and unfinished work must remain available across assistants and sessions; its work context guide explains that routine.

What should stay out of the shared instruction file?

Keep credentials, private machine paths, and temporary debugging output elsewhere. A shared instruction file should not grow into a transcript of every session. Add a durable rule when it helps future tasks; record a task’s changing status with the task.

After the migration, give both tools the same small starting agreement: read the repository guidance, read the active work record, perform the authorized task, and save what remains. The switching models hub covers the wider problem of carrying work between AI apps.