Most bad agent migrations start with a file copy.
That is the wrong unit of migration.
A coding-agent setup is not one configuration file. It is project instructions, MCP servers, lifecycle automation, permissions, and memory. Two clients can support all five and still implement them differently. Copying folders blindly is how you end up with a tool that starts, has too many permissions, and behaves differently at the exact moment you need it to be predictable.
I moved part of my own workflow from Claude Code to Codex after GPT-5.6. The useful part was not “which model wins.” It was rebuilding the workflow in small, testable surfaces.
1. Instructions: adapt, do not copy
Take the durable rules from your project instructions: source of truth, allowed files, test command, security boundaries, and definition of done. Rewrite any client-specific command or permission language in terms of observable outcomes.
The first test is not a refactor. Ask the new agent to summarize the rules, then give it a non-destructive task. If the summary or scope is wrong, the migration is not ready.
2. MCP: port one read-only server first
MCP is useful because it gives a model controlled access to real tools. It is not magic portability. A server may have different authentication, working-directory, approval, or write-scope behavior in another client.
Start with a read-only action. Test the success path, then a bad request. Only grant a write path once its rollback and audit record are clear.
3. Hooks: migrate the outcome
Do not look for a one-to-one hook name. Write down the outcome you wanted: restore a small task context at session start, block an unsafe action before execution, or record a useful checkpoint at stop. Then rebuild that outcome using the target client’s available lifecycle surface.
The rule is simple: inventory → port one bounded surface → run a real task → compare output → keep or roll back.
4. Permissions: re-authorize
The right migration starts read-only. Do not drag a broad allowlist into a new client simply because it worked before. Add filesystem, network, and destructive capabilities only when a bounded task proves the need.
5. Memory: test retrieval, not storage
Memory is not a longer context window. It is a retrieval design: what gets stored, who can access it, what source proves it, and how you detect a stale fact.
Keep the working set small: objective, files, tests, sources, assumptions. Retain only verified decisions, constraints, corrections, and source links.
That is the entire playbook. It is not glamorous, but it works because every stage has a rollback point.
The full guide includes the model-routing, local-MCP, and context-discipline framework: How I Use Codex After GPT-5.6.
Top comments (0)