Access LinkedIn profiles, posts, media uploads, public libraries, and advertising APIs through managed OAuth.
Integrations
migrate-to-codex
Migrate selected Claude Code instructions, skills, hooks, agents, MCP servers, and config into validated Codex files.
What it does
Migrates selected global or project Claude Code surfaces into Codex instructions, skills, hooks, config, MCP servers, and custom agents. It scans and plans first, performs a dry run, writes Codex artifacts without modifying source files, then inspects reports and fixes resolvable migration issues. Validation and dry-run checks are repeated until no actionable generated-artifact fixes remain, followed by a scoped markdown report.
When to use it
- Moving project instructions from Claude Code to Codex
- Converting slash commands into Codex skills
- Porting MCP servers and supported hooks
- Migrating subagents into Codex custom agents
The skill document
Migrate to Codex
Autonomy
Keep going until the selected migration is completely done: run the migrator, inspect the report, fix migrated Codex instructions/skills/agents/MCP config, and re-run checks without stopping to ask for confirmation of the next step. If the user has selected a target, do not ask before creating, editing, replacing, or deleting generated Codex artifacts in that target (AGENTS.md, .codex/, .agents/, or ~/.codex/). Preserve unrelated existing Codex config entries in .codex/config.toml or ~/.codex/config.toml, such as notify, projects, marketplaces, or unrelated MCP servers; do not ask about them unless they fail validation or directly conflict with the migration. Do not edit source Claude Code files (.claude/, ~/.claude/, .mcp.json, or .claude.json), unrelated project code, secrets, or another repository.
Migration Order
Run the migration in this order for each selected global or project source:
-
Start by using Codex's built-in TODO/task list tool. Do not create
MIGRATION_TODOS.mdor any TODO file unless the user explicitly asks. The TODO list input has aplanarray whose items each havestepandstatus; use statusespending,in_progress, andcompleted. Make the TODOs specific to the selected artifacts. Before finishing, update the TODO list so every finished step is markedcompletedand no step remainsin_progress. Use literal source → Codex target labels, for example:- Inspect
.claude/commands→ Codex skills/prompts - Inspect
.claude/agents→.codex/agents - Inspect
.mcp.json→.codex/config.tomlMCP servers - Inspect
.claude/settings.jsonhooks →.codex/hooks.json - Migrate safe selected artifacts → Codex files
- Validate generated
.codex/config.toml - Validate generated
.codex/agents - Report migrated artifacts and manual-review items
- Inspect
-
Read
references/differences.md(and refresh Codex docs if itsDocs last checkeddate is old). -
Scan and inspect before writing:
--scan-onlylists active and inactive source surfaces.--planprints staged Codex artifact paths and report rows.--doctorsummarizes readiness, manual-review work, and validation risks.
-
Convert surfaces in the same order the CLI uses:
- instructions:
CLAUDE.md/AGENTS.mdtoAGENTS.md - plugins: report Claude plugin trees and marketplaces as manual migration work
- hooks: rewrite supported Claude hooks into
.codex/hooks.jsonand enable[features].codex_hooks = true - skills and commands: write Codex skills under
.agents/skills/ - config: write
.codex/config.tomlfrom Claude model/sandbox settings and MCP servers, includingpersonality = "friendly"when config is generated - subagents: write Codex custom agents under
.codex/agents/
- instructions:
-
Dry-run, then write the selected target. Use
--replaceonly when orphan generated skills or agents should be deleted. -
Inspect the terminal output and
.codex/migrate-to-codex-report.txtafter real runs. -
Review generated artifacts in this order:
AGENTS.md,.agents/skills/,.codex/config.toml,.codex/hooks.json,.codex/agents/, then report-only plugin items. -
Run
--validate-targetagainst each target after edits. -
Re-run checks and
--dry-runafter edits. -
Return the final migration report as one markdown table per scope that has rows. The tables cover only the non-native follow-up migration work you performed, such as skills created from slash commands, subagents, MCP servers, hooks, unsupported/local plugin notes, and manual-review caveats. Include programmatic native import rows for config, instructions, skills, or supported plugins only if you personally migrated them in this follow-up run.
If only one scope has rows, render only the table with no heading. If multiple scopes have rows, render one heading before each table. Use
**User Config**for user-scope rows. For project-scope rows, use the actual project folder name as the heading, for example**northstar-support-portal**; do not useCurrent Projectas the heading. Do not add prose before or after the table output.Use exactly these columns:
northstar-support-portal
Status Item Notes AddedSlash commandpr-reviewConverted into a Codex skill AddedSubagentrelease-leadAdded as a Codex subagent Check before usingHookPreToolUseConverted, but some Claude hook behavior differs in Codex Not AddedHookNotificationCodex does not have an equivalent notification hook Not AddedPluginteam-macrosPlugin needs manual setup Statusmust beAdded,Check before using, orNot Added. UseAddedwhen a Codex-facing artifact was created or changed and needs no special review. UseCheck before usingwhen a Codex-facing artifact was created or changed but the migration changed semantics, inferred behavior, preserved tool rules as guidance, or dropped unsupported behavior. UseNot Addedwhen a source artifact was detected but no Codex-facing artifact was created.Itemcombines the artifact type and concrete item name in one cell. Artifact type must be singular:Skill,Slash command,Subagent,MCP,Hook, orPlugin. Wrap the artifact type in inline code; write the item name as plain text after it.Notesis always required; never leave it empty. Keep notes short, plain, and literal. Avoid internal implementation terms such as runtime expansion. Prefer phrases likeConverted into a Codex skill,Added as a Codex subagent,Added to Codex config,Converted into a Codex hook,Converted, but some Claude hook behavior differs in Codex,Codex does not have an equivalent notification hook,Plugin needs manual setup, orPlugin marketplace needs manual setup.
Self-Healing Loop
Keep looping until the selected migration is complete:
- Run
--planor--doctor. - Run the migration with
--dry-run. - Run the migration for real.
- Fix every generated
## MANUAL MIGRATION REQUIREDblock and everymanual_fix_requiredorskippedreport row that can be resolved inside Codex artifacts. - Run
--validate-target. - Re-run the migrator and validator until the report and validator have no actionable generated-artifact fixes left.
Do not edit source Claude Code files, unrelated project code, secrets, or another repository during this loop. If a report row requires source-provider changes or product judgment, leave the generated Codex artifact with clear manual guidance instead of changing the source.
Commands
Choose the migrator command.
MIGRATE_TO_CODEX='python3 .codex/skills/migrate-to-codex/scripts/migrate-to-codex.py'
Inspect the migration before writing.
$MIGRATE_TO_CODEX --source ~/.claude/ --scan-only
$MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --plan
$MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --doctor
Dry-run, then run without --dry-run, for global and project.
$MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/ --dry-run
$MIGRATE_TO_CODEX --source ~/.claude/ --target ~/.codex/
$MIGRATE_TO_CODEX --source ./.claude/ --target ./.codex/ --dry-run
$MIGRATE_TO_CODEX --source ./.claude/ --target ./.codex/
Run the post-migration validator against each target after edits.
$MIGRATE_TO_CODEX --validate-target ~/.codex/
$MIGRATE_TO_CODEX --validate-target ./.codex/
Run $MIGRATE_TO_CODEX --help for flags (--scan-only, --plan, --doctor, --validate-target, defaults, and so on). Deep tables and more links are in references/differences.md.
Questions people ask
- Which source artifacts can it migrate?
- It handles CLAUDE.md or AGENTS.md instructions, commands and skills, supported hooks, model and sandbox config, MCP servers, and subagents. Plugin trees and marketplaces are reported as manual migration work.
- Does it overwrite existing Codex configuration?
- It may create, edit, replace, or delete generated artifacts in the selected target. Unrelated entries in existing config.toml files, including notify, projects, marketplaces, and unrelated MCP servers, are preserved unless they conflict or fail validation.
- How does it verify the migration?
- It scans, plans, runs readiness checks, performs a dry run, and validates each target after writing. It reviews generated artifacts and migration reports, fixes resolvable Codex-side issues, and repeats checks until no actionable generated-artifact fixes remain.
Related skills
Access and manage GitHub resources through the REST API with managed OAuth connections.
Read and manage Outlook mail, folders, calendars, and contacts through Microsoft Graph.
Query and manage Linear work items through GraphQL with managed OAuth authentication.
Query and manage Salesforce sObjects through REST APIs with managed OAuth and explicit write approvals.
Manage Asana tasks, projects, users, workspaces, and webhooks through managed OAuth APIs.
More from OpenAI
Browse all skillschatgpt-apps
OfficialPlan, scaffold, refactor, and validate ChatGPT Apps SDK projects with an MCP server and widget UI.
figma-generate-design
OfficialBuild or update full-page Figma screens with linked design-system components, variables, and styles.
figma-generate-library
OfficialBuilds a code-aligned Figma design system through phased creation, validation, and user approval.
figma-use
OfficialRuns Figma Plugin API scripts with the required call parameters, API rules, IDs, and validation workflow.
hatch-pet
OfficialCreate and validate a Codex-compatible animated pet atlas from concepts, brand cues, or reference art.
imagegen
OfficialGenerate or edit raster assets, validate the result, and place selected files into the project workspace.