Migrate supported instruction files, skills, agents, and MCP config into Codex project and global files.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionmigrate-to-codexExecute the skills CLI command in your project's root directory to begin installation:
Fetches migrate-to-codex from OWNER/REPO and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate migrate-to-codex. Access via /migrate-to-codex in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
0
upvotes
Run in your terminal
0
installs
0
this week
—
stars
| name | migrate-to-codex |
| description | Migrate supported instruction files, skills, agents, and MCP config into Codex project and global files. |
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.
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.md or any TODO file unless the user explicitly asks. The TODO list input has a plan array whose items each have step and status; use statuses pending, in_progress, and completed. Make the TODOs specific to the selected artifacts. Before finishing, update the TODO list so every finished step is marked completed and no step remains in_progress. Use literal source → Codex target labels, for example:
.claude/commands → Codex skills/prompts.claude/agents → .codex/agents.mcp.json → .codex/config.toml MCP servers.claude/settings.json hooks → .codex/hooks.json.codex/config.toml.codex/agentsRead references/differences.md (and refresh Codex docs if its Docs last checked date is old).
Scan and inspect before writing:
--scan-only lists active and inactive source surfaces.--plan prints staged Codex artifact paths and report rows.--doctor summarizes readiness, manual-review work, and validation risks.Convert surfaces in the same order the CLI uses:
CLAUDE.md / AGENTS.md to AGENTS.md.codex/hooks.json and enable [features].codex_hooks = true.agents/skills/.codex/config.toml from Claude model/sandbox settings and MCP servers, including personality = "friendly" when config is generated.codex/agents/Dry-run, then write the selected target. Use --replace only when orphan generated skills or agents should be deleted.
Inspect the terminal output and .codex/migrate-to-codex-report.txt after 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-target against each target after edits.
Re-run checks and --dry-run after 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 use Current Project as the heading. Do not add prose before or after the table output.
Use exactly these columns:
northstar-support-portal
| Status | Item | Notes |
|---|---|---|
Added | Slash command pr-review | Converted into a Codex skill |
Added | Subagent release-lead | Added as a Codex subagent |
Check before using | Hook PreToolUse | Converted, but some Claude hook behavior differs in Codex |
Not Added | Hook Notification | Codex does not have an equivalent notification hook |
Not Added | Plugin team-macros | Plugin needs manual setup |
Status must be Added, Check before using, or Not Added. Use Added when a Codex-facing artifact was created or changed and needs no special review. Use Check before using when a Codex-facing artifact was created or changed but the migration changed semantics, inferred behavior, preserved tool rules as guidance, or dropped unsupported behavior. Use Not Added when a source artifact was detected but no Codex-facing artifact was created. Item combines the artifact type and concrete item name in one cell. Artifact type must be singular: Skill, Slash command, Subagent, MCP, Hook, or Plugin. Wrap the artifact type in inline code; write the item name as plain text after it. Notes is always required; never leave it empty. Keep notes short, plain, and literal. Avoid internal implementation terms such as runtime expansion. Prefer phrases like Converted 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, or Plugin marketplace needs manual setup.
Keep looping until the selected migration is complete:
--plan or --doctor.--dry-run.## MANUAL MIGRATION REQUIRED block and every manual_fix_required or skipped report row that can be resolved inside Codex artifacts.--validate-target.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.
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.
Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
googlecolab/google-colab-cli
OWNER/REPO
kunchenguid/no-mistakes
openai/skills
BuilderIO/skills
mattpocock/skills
migrate-to-codex fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
migrate-to-codex reduced setup friction for our internal harness; good balance of opinion and flexibility.
Useful defaults in migrate-to-codex — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
Registry listing for migrate-to-codex matched our evaluation — installs cleanly and behaves as described in the markdown.
migrate-to-codex has been reliable in day-to-day use. Documentation quality is above average for community skills.
Useful defaults in migrate-to-codex — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
migrate-to-codex has been reliable in day-to-day use. Documentation quality is above average for community skills.
migrate-to-codex is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
I recommend migrate-to-codex for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
Registry listing for migrate-to-codex matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 51