MODULE 2.1 / 4 OF 9
Claude → Codex: Separate the brain from the model
Explain why lock-in lives in the runtime and how the Audit → Adapt → Prove → Handoff method moves project knowledge into a portable core.
Area page: eventos.inema.pro/claude-codex/en/ · in the menu: “migrate or stay tool-agnostic”
1The thesis: separate the brain from the model
What it is
The Claude → Codex area starts with one statement: “Don’t migrate your brain. Separate the brain from the model.” The “brain” is everything you’ve accumulated in a project: context, rules, decisions, tasks, skills, handoffs, and memory. According to the page, only CLAUDE.md and AGENTS.md are tied to a provider; everything else is portable Markdown, plain text that any agent can read. When that material lives in a portable layer inside the project, Claude Code, Codex CLI, Gemini, or a local model in a container become just executors: programs that do the work based on those files. Switching models becomes a change at the boundary, not at the center. The area brings together the thesis, the method, a course with 3 tracks, a kit of scripts, and mega-prompts that put it into practice.
Why learn it
Models change often because of price, access, or quality. If your project knowledge is in the right place, each switch costs little instead of requiring you to rebuild it.
Key concepts
brain = context, rules, decisions, tasks, skills, handoffs, and memory; portable Markdown; executor; change the boundary, not the center
In practice
An analyst has used a coding assistant for months, and the team decides to try another one. Because the project’s rules and decisions are in Markdown files in the repository, the new executor reads the same files and continues the work.
✓ Do
List three things your agent “knows” about a project today and note where each one is stored.
✗ Avoid
Judging the area by its name: read the main idea on the page before deciding if it’s for you.
2Lock-in lives in the runtime
What it is
Lock-in means being tied to a provider because leaving would be costly. The page states: “Lock-in isn’t in the model. It’s in what you’ve left inside the runtime.” The runtime is the program that runs the agent, such as Claude Code or Codex CLI. Someone who has used a coding assistant for a few months may have accumulated instructions, memory, skills, hooks, and thousands of sessions in a format only that runtime can read. The page describes three changes: lock-in is invisible until the day you switch; the same knowledge can work with any model; and you have less dependence and more control. The content lasts; the format is disposable. Mixing them is what makes migration harder.
Why learn it
This area is for people who use Claude Code or Codex on real projects and worry about switching models. Understanding where the dependence lives shows what needs to move out of the runtime before a switch becomes necessary.
Key concepts
lock-in; runtime; CLAUDE.md, native memory, and JSONL sessions store the work; they aren’t the work; durable content, disposable format
In practice
A developer discovers that the project’s most important decisions exist only in the assistant’s session history. When they switch tools, no one knows why certain choices were made because nothing was recorded outside the runtime.
3The method: audit before you change
What it is
The method has four steps, in this order: Audit, Adapt, Prove, and Handoff, “never implementing before auditing.” Auditing means making a read-only inventory of both runtimes: skills, commands, subagents, hooks, and MCP. Each skill is classified as reusable, an adapter, native, or unresolved. Adapting means splitting the CLAUDE.md: portable rules go into AGENTS.md, while anything that depends on a Claude plugin, hook, or menu stays in the specific file, which imports only the portable rules. Proving means opening a new session and asking five continuity questions: the goal and success criteria, a rule and its source file, the last decision, the next action, and any conflicts. Handoff means recording decisions, open items, next steps, and paths in a Markdown file that the next session reads before acting.
Why learn it
This order avoids the costliest mistake: changing files before you know what’s there. The proof rule also keeps you from confusing a created file with knowledge the agent actually used.
Key concepts
Audit → Adapt → Prove → Handoff; MODE: audit; portable × residue; five continuity questions; file existence is not proof
In practice
A team wants to move a project to Codex. First, it runs the audit, which only reads and classifies. Then it splits the CLAUDE.md. Finally, it opens a new session and checks whether the agent can name the next action and cite the right file.
Steps to try
- Open the area page beside this lesson.
- Write the five continuity questions in a file, then answer each one and point to its source file.
- Write one sentence about what changed in your understanding.
4The portable core, file by file
What it is
The portable core has seven places, each with an owner and an update rule. AGENTS.md holds stable rules and the reading order; context/overview.md, verified facts with their sources and dates; context/current-state.md, what works and what’s pending; context/sources.md, where each piece of information comes from. context/decisions/ holds one accepted decision per file; tasks/current.md states the goal, owner, success criteria, and next action; handoffs/latest.md prepares the next session to continue. The page explains that these names are conventions: no runtime loads these folders on its own. The reading order at the top of AGENTS.md tells it to read them. Each piece of information has a type: fact, preference, hypothesis, or decision, and “provenance wins over timestamp,” meaning the source matters more than the date and nothing is deleted; use superseded_by instead.
Why learn it
Mixing facts with hypotheses, or decisions with preferences, can make the agent repeat old mistakes and contradict what’s already been resolved. Owners and dates let you promote information to approved context, always with your approval.
Key concepts
AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; fact, preference, hypothesis, decision; provenance wins over timestamp; keep secrets out of the repository
In practice
In a project with conflicting old decisions, each accepted decision gets its own file in context/decisions/. When one is replaced, it isn’t deleted: it gets the superseded_by marker, and the agent stops following the old rule.
✓ Do
In a test project, create tasks/current.md with the goal, owner, success criteria, and next action.
✗ Avoid
Jumping to the tool or course without understanding the problem the area addresses.
5Migrate or stay model-agnostic
What it is
The page breaks the decision into three effort levels, not opinions. Level 1 is to import in the app with one click: it’s quick, but limited to what the other side accepts. The Codex CLI, for example, has no native import. Level 2 is to migrate with the kit using one command: run the agente-claude-codex scripts to audit, adapt, install the core, port skills, and prove. Level 3 is a durable, portable personal layer: knowledge lives in the project, and the runtime is interchangeable. Staying model-agnostic, meaning you don’t depend on any specific model, is Level 3 and, according to the page, the only option that survives the next switch. Being model-agnostic doesn’t mean leaving Claude: you can still choose the executor for each task.
Why learn it
Not everyone needs Level 3 right now. The page lists when to migrate now, due to cost, access, or policy, and when it makes sense to stay model-agnostic, such as when you use two executors or work with client projects.
Key concepts
Level 1: import; Level 2: migrate with the kit; Level 3: portable personal layer; migrate now × stay model-agnostic; cost of doing nothing
In practice
A consultant needs to use Codex this week because of a client policy and has few skills, almost all in plain Markdown: this is a case for migrating now. Another consultant has already switched tools once and doesn’t want to rebuild everything: this is a case for staying model-agnostic.
6Course, kit, and the first step
What it is
The course Claude → Codex: migrate or stay model-agnostic is free and available in Portuguese, with English and Spanish versions. According to the curriculum, it has 3 tracks, 18 modules, and 108 topics. Track 1 covers fundamentals and vocabulary, Track 2 walks through the kit command by command, and Track 3 presents six projects based on a real system. The agente-claude-codex kit uses bash and Markdown, with three ways to use it: scripts, mega-prompts, and the portable core template. doctor.sh answers “is my environment ready?” and audit.sh saves a read-only report. The kit also includes adapt-instructions.sh, init-core.sh, sync-skills.sh with polyskill, readback-test.sh, drift-report.sh, and promover-memoria.sh. The page sums it up: “The best first step is one of your own projects, in audit mode.”
Why learn it
The course explains why, and the kit does the work without deleting anything: nothing in ~/.claude or ~/.codex is copied in bulk or deleted, and installing a skill creates a backup alongside it. Starting with the audit shows you in one session what’s portable and what depends on a hook.
Key concepts
3-track course; agente-claude-codex kit; doctor.sh; audit.sh; mega-prompts A and B; Topic Map; sister area Codex + Claude
In practice
An IT manager wants to evaluate a tool switch without risk. She clones the kit, runs doctor.sh, reads the audit, and only then decides which migration level makes sense for the team.
Criteria for reviewing your worksheet
Use this rubric after the lab. Each row asks for evidence; marking a topic as read doesn’t mean the worksheet is complete.
| Criterion | Expected evidence | If it doesn’t meet the criterion |
|---|---|---|
| Main idea | You can describe the area in one sentence that reflects the page. | Reread the top of the page and topic 1. |
| Audience | You can say who the area is for and who it isn’t for. | Return to topic 2 and write an example from your work. |
| Core elements | You can name the area’s core elements. | Use the module diagram as a guide. |
| First step | You chose a small, concrete step. | Copy the first step recommended on the page itself. |
| Starting point | You know which course, kit, or project to open first. | Check topic 6 and the page’s access section. |
| Source | Every statement in the worksheet comes from the page. | Replace your assumptions with what the page says. |
HANDS-ON / ~10 MIN
Your first audit in audit mode
Keep the area page open: https://eventos.inema.pro/claude-codex/en/. Use an example from your work, without personal or client data.
Prompt: read-only audit of your project
Paste it into Claude, ChatGPT, or Codex. Replace the words inside < and > with details about your situation.
MODE: audit
Read https://eventos.inema.pro/claude-codex/ to understand the Audit → Adapt → Prove → Handoff method.
Then, without changing any files, inventory this project: <path to your project folder>.
1. List the instructions (CLAUDE.md, AGENTS.md), skills, commands, hooks, and MCPs you find.
2. Classify each skill as reusable, an adapter, native, or unresolved.
3. Separate CLAUDE.md into portable lines (move to AGENTS.md) and Claude-specific residue.
4. Say which of the five continuity questions (objective and done criteria, one rule with its source file, last decision, next action, conflicts) the current files already answer.
Return only the report and a plan. Don’t implement anything.
Completion criterion
Explain why lock-in lives in the runtime and how the Audit → Adapt → Prove → Handoff method moves project knowledge into a portable core. Keep the worksheet with the main idea, audience, first step, and starting point.
Open the area page ↗Review what you’ve learned
A colleague says migrating from Claude to Codex is just copying CLAUDE.md somewhere else. What’s missing from that idea?
View suggested answer
You need to separate what’s portable from what’s runtime residue, then prove it in a new session. As the page says, having a file isn’t proof; the agent must have read and used it.
If your answer was different, return to the relevant topic and describe the difference in one sentence. This check won’t block your progress.
Module summary
- brain = context, rules, decisions, tasks, skills, handoffs, and memory; portable Markdown; executor; change the boundary, not the center
- lock-in; runtime; CLAUDE.md, native memory, and JSONL sessions store the work; they aren’t the work; durable content, disposable format
- Audit → Adapt → Prove → Handoff; MODE: audit; portable × residue; five continuity questions; file existence is not proof
- AGENTS.md; context/; decisions/; tasks/current.md; handoffs/latest.md; fact, preference, hypothesis, decision; provenance wins over timestamp; keep secrets out of the repository
- Level 1: import; Level 2: migrate with the kit; Level 3: portable personal layer; migrate now × stay model-agnostic; cost of doing nothing
- 3-track course; agente-claude-codex kit; doctor.sh; audit.sh; mega-prompts A and B; Topic Map; sister area Codex + Claude
Check the source
Pages read on 28/09/2026. Area content changes; the official page takes precedence over this summary.