MODULE 2.1
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.
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
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
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
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
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
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