本文へ移動
📥

Claude CodeやCursorで育てたinstructions、skills、MCP設定をCodexでも使いたい。しかし、ファイルを丸ごとコピーすると、権限モデルや設定名の違いまで持ち込み、動いているように見えて安全境界だけが変わることがあります。

2026年8月11日に、ChatGPT desktop appとCodex CLIの agent import が公式公開されました。desktop appはClaude Code、Claude Cowork、Cursorから、Codex CLIの /import はClaude CodeとCursorから、対応する設定とrecent workを取り込めます。

この記事では、/import を単なるコピー機能としてではなく、別agentの設定をCodexの制御面へ変換し、差分を再審査するmigration workflowとして扱います。instruction fileの責務は AGENTS.md と CLAUDE.md の違い、pluginとskillの分担は Codex Plugins と Skills の違い、製品全体の違いは Claude Code vs Codex CLI 比較、import後の外部接続審査は Codex plugin governance 設計ガイド に分けています。

先に結論: import直後を完了状態にしない

安全な移行は次の順です。

  1. 元agentの設定をinventory化する
  2. 自動更新をOFFにした状態でimportする
  3. 生成されたCodex側の差分を確認する
  4. MCP、hooks、plugins、agentsの権限を再審査する
  5. 認証をやり直す
  6. read-only taskで動作確認する
  7. 問題がなければautomatic updatesを検討する

import completed は、変換処理が終わっただけです。組織の運用上は、review completed になって初めて利用可能とします。

desktop appとCodex CLIの違い

公式docsでは、import元と実行面が次のように分かれています。

実行面import元主な特徴
ChatGPT desktop appClaude Code、Claude Cowork、CursorSettingsから選択し、automatic updatesを使える
Codex CLI /importClaude Code、Cursorterminal内で対象を選び、Codex設定をレビューする

desktop appは、importしたpluginやconnectionに追加setupが必要な場合、status cardから Finish を促します。CLIは手元の開発環境で設定変換を確認しやすい反面、running task中やremote sessionでは使えません。

使い分けは単純です。

  • UIでprojectやchatを選び、継続同期したい: desktop app
  • repoごとに設定差分を見ながら移したい: Codex CLI
  • Claude Coworkから移したい: desktop app
  • CIやautomationから自動実行したい: どちらも避け、人間のmigration taskにする

/import の基本手順

Codex CLIではlocal sessionを開始し、slash commandを実行します。

/import

その後、Claude CodeまたはCursorを選び、対応するsetup、project file、recent chatを選択します。

公式docs上の制約は次の通りです。

  • 直近30日から最大50 chatsをimportできる
  • running task中は使えない
  • remote sessionでは使えない
  • local app-server daemonへ接続中は使えない

この制約は不便ではなく、migrationと実作業を混ぜないための境界として使えます。作業中のsessionへ設定を差し込むと、同じtask内で前半と後半のtool policyが変わってしまいます。

desktop appからimportする

desktop appでは次の順です。

  1. Settings > Import を開く
  2. Import を選ぶ
  3. Claude Code、Claude Cowork、Cursorから対象を選ぶ
  4. importするitemを選ぶ
  5. 完了後、imported projectまたはchatを開く
  6. status cardに未完了項目があれば Finish する

環境によってImportが独立sectionに見えない場合は、General内の Import other agent setup を確認します。

automatic updatesは便利ですが、初回からONにしない方が安全です。元agent側の設定変更が、Codex側で未レビューのpermission changeになる可能性があるからです。

何がどこへ変換されるか

importの核心はfile copyではなく、Codex側の概念へのmappingです。

import対象Codex側のdestination
instruction filesAGENTS.md
settings.jsonconfig.toml
skillsSkills
pluginsPlugins
既存project folder同じfolderを使うProjects
Claude Codeのproject memoriesMemories
直近30日のchatChatGPT chats
MCP server configurationCodex MCP configuration
hooksCodex hooks
slash commandsSkills
subagentsCodex agents

この表を見ると、reviewすべき場所が分かります。たとえばslash commandはそのままslash commandへ行くのではなく、Skillへ変換されます。Claude Codeのsubagentも、同じruntime semanticsのままではなくCodex agentになります。

名前が対応していても、実行条件と権限が同じとは限りません。

元agentを変更・削除しない

公式docsでは、importは既存agent setupを変更または削除しないと説明されています。これはrollbackしやすい設計です。

ただし、同じproject folderをClaude CodeとCodexの両方が使う場合、repo内の共有fileは別です。たとえば AGENTS.md、CLAUDE.md、.claude/、.codex/、plugin manifestを同じbranchで編集すれば、import機能とは別に相互影響します。

移行期間中は、次を分けて記録します。

migration_scope:
  source_agent: claude-code
  target_agent: codex
  source_setup_mutation: forbidden
  shared_project_files:
    - AGENTS.md
    - CLAUDE.md
  target_only_files:
    - ~/.codex/config.toml
  review_owner: platform-engineering

「sourceは変わらない」と「共有repoに影響しない」は別の話です。

import前にinventoryを取る

import画面で Import all を押す前に、元agentの制御面を一覧にします。

最低限、次を記録します。

項目確認内容
instructionsuser / project / directoryのscope
settingsmodel、permission、sandbox、network
MCPendpoint、transport、auth、scope、owner
hooksevent、command、timeout、外部副作用
skills / commands読むfile、実行command、引数展開
pluginsmarketplace、underlying app、requested permissions
subagentstools、model、memory、write permission
chats / memoriescustomer data、secrets、古い前提

inventoryがないと、import後に何が増えたか分かりません。

CLAUDE.md をそのまま AGENTS.md と考えない

instruction filesは AGENTS.md へ移りますが、内容を無条件で採用するのは危険です。

Claude Code固有のcommand、permission mode、hook名、marketplace前提が含まれている場合、Codexでは意味が変わるか、単に効きません。反対に、CodexのAGENTS.mdはdirectory scopeで自動発見されるため、元より広い範囲へ効く可能性もあります。

変換後は文ごとに分類します。

  • host-neutralなrepo rule: AGENTS.md に残す
  • Claude Code固有: CLAUDE.md に残すか削除する
  • task固有の手順: Skillへ移す
  • 過去の学び: Memory候補として短くする
  • 一時的な状態: importしない

同じ内容を AGENTS.md と CLAUDE.md の両方に残すと、将来必ずずれます。

settings.json から config.toml への変換を差分で見る

設定fileのsyntaxが変わるだけではありません。permission、sandbox、network、approval reviewerのdefaultがCodex側の概念へ変換されます。

レビュー時は値より先に、設定がどのscopeへ置かれたかを見ます。

  • user全体へ効くのか
  • projectだけへ効くのか
  • profileとして選択時だけ効くのか
  • local machine固有か
  • managed policyと競合しないか

たとえば元agentで「read-only調査用」だった設定が、Codexのdefault profileへ入ると、別taskにも影響します。逆に安全設定が狭すぎるscopeへ入ると、通常profileでは効きません。

MCP設定は必ず再認証する

import対象にはMCP server configurationも含まれます。ここが最重要review pointです。

公式docsも、custom authentication、headers、environment variables、transportを使うMCP設定は再確認し、必要ならsign-inし直すよう案内しています。

再審査する項目は次です。

  • endpointが同じownerのものか
  • stdio / remote HTTPのtransportが正しいか
  • tokenが別agentのcredential storeに依存していないか
  • custom headerにsecretが埋め込まれていないか
  • OAuth scopeがCodex taskに必要か
  • write toolが自動許可されていないか
  • server catalogのreview dateが有効か

credential fileをコピーして「動いた」で終わらせません。認証はtarget agent側でやり直し、最小scopeのtokenを発行します。

hooksはcommandだけでなくevent semanticsを確認する

Claude CodeとCodexのhooksは、名前が似ていてもpayload、実行タイミング、blocking behaviorが同じとは限りません。

import後に確認する順番は次です。

  1. どのeventで起動するか
  2. stdin / environmentに何が渡るか
  3. exit codeがallow / deny / errorのどれになるか
  4. commandがどのworking directoryで動くか
  5. networkや外部writeを行うか
  6. timeout時にtaskがどうなるか

特にshell interpolationとpath placeholderは危険です。元agentで安全だった引用方法が、変換後のrunnerで同じとは限りません。

初回テストは、外部副作用のないhookだけ有効にします。

slash commandsからSkillsへの変換を見直す

slash commandは短いprompt templateとして使われがちですが、Codex Skillはinstructions、scripts、references、assetsを含む再利用単位です。

変換後に次を確認します。

  • descriptionが発火条件を限定しているか
  • argumentが欠けても危険なdefaultへ進まないか
  • scriptがsource agent固有pathを参照していないか
  • secretsやpersonal pathを含んでいないか
  • task外のfileやexternal systemへ書き込まないか

command名が同じでも、Codexが自律的にSkillを選ぶ条件が広いと、意図しないtaskで実行されます。

subagentsからCodex agentsへの変換を最小権限で確認する

subagentの役割定義をimportできても、tool access、memory、parallel execution、worktreeの扱いは再確認が必要です。

最初の動作確認では次のように縮小します。

agent_review:
  name: imported-reviewer
  allowed_tools:
    - read
    - search
    - git-diff
  denied_effects:
    - file-write
    - network-write
    - credential-read
  test_task: review-one-local-diff

reviewerやresearcherから試し、write agentは最後にします。import元で承認されていた権限を、そのままtargetへ持ち越さないのが原則です。

recent chatsとproject memoriesは古い前提を持ち込む

recent chatsを移せると、途中の作業を続けやすくなります。ただし、chatは正規の仕様書ではありません。

持ち込みやすい問題は次です。

  • すでにmerge済みのbranchを作業中と誤認する
  • 古いAPIやmodel名を使う
  • 以前だけ許可された例外を通常ルールとみなす
  • 顧客Aの文脈を顧客Bのprojectへ持ち込む
  • chat中のsecretや個人情報が残る

imported chatを開いたら、最初にcurrent repo stateと公式docsを確認します。chatはcontinuityの補助であり、truth sourceではありません。

import後のreview manifestを残す

移行結果を人の記憶だけに残さず、小さいmanifestへ落とします。

agent_import_review:
  imported_at: "2026-08-14"
  source: "claude-code"
  destination: "codex"
  reviewed:
    instructions: approved_with_changes
    settings: approved
    skills: approved_with_changes
    plugins: pending_auth
    mcp: pending_scope_review
    hooks: disabled_for_test
    agents: read_only_only
    chats: selected_only
  automatic_updates: false
  next_review: "2026-08-21"

このmanifestがあれば、何が未審査かを明確にできます。

最初の検証taskはread-onlyにする

import直後に実装やdeployを任せず、次のようなtaskで確認します。

このrepositoryを変更せずに調査してください。
1. 読み込んだAGENTS.mdのpathを列挙する
2. 有効なSkillとAgentを列挙する
3. 接続可能なMCP server名だけを示す
4. hooksを実行しない
5. git statusとbuild commandを報告する

確認したいのは回答品質より、制御面です。

  • 想定したinstructionsだけ読んだか
  • 不要なpluginやMCPが有効になっていないか
  • credential promptが適切に出るか
  • hookが勝手に外部操作しないか
  • 元agentのpathへ書き込まないか

このtestを通してから、小さいfile editへ進めます。

automatic updatesは差分レビューを作ってからONにする

desktop appでは、import元の変更をautomatic updatesで同期できます。継続移行には便利ですが、組織利用ではcontrol planeの変更経路になります。

ONにする条件は次です。

  • source ownerが決まっている
  • 同期対象を限定できる
  • 更新履歴を確認できる
  • MCP / plugin / hookのpermission changeを検知できる
  • 問題時に同期を止められる
  • target側のlocal修正と競合したときの優先順位が決まっている

特にpersonal setupをteam Codex環境へ同期しないようにします。sourceとdestinationのownerが違うなら、automatic updatesではなく定期的なreviewed importが安全です。

よくある失敗

Import all を選び、そのまま使う

chatやmemoryまで含めると、不要な文脈が大量に入ります。用途ごとに選択します。

MCPが接続できたので安全だと判断する

接続成功はscopeやtool riskを保証しません。認証と承認境界を再審査します。

CLAUDE.md と AGENTS.md を二重管理する

共通ルールのsource-of-truthを1つにします。製品固有差分だけを分けます。

source agentのcredentialをそのまま使う

target側で再認証し、taskに必要な最小scopeへ落とします。

automatic updatesを最初からONにする

どの差分が同期されたか追えなくなります。初回reviewが終わるまではOFFにします。

migration checklist

  • source agentのinventoryを作った
  • import対象を個別に選んだ
  • AGENTS.md のscopeと内容を確認した
  • config.toml のpermission / sandbox / networkを確認した
  • MCPをtarget側で再認証した
  • hooksのevent、payload、exit code、side effectを確認した
  • slash commandsから変換されたSkillsを確認した
  • imported agentsをread-onlyから試した
  • chatsとmemoriesから古い前提・機密情報を除いた
  • read-only verification taskを実行した
  • automatic updatesをOFFのまま初回reviewした
  • review manifestとownerを残した

まとめ

Codex /import は、Claude CodeやCursorで積み上げた作業資産を捨てずに移れる強い機能です。特にinstructions、skills、MCP、hooks、recent chatsを同じmigration flowで扱えるため、agent切り替えのコストを下げられます。

一方で、安全性はimportできるかではなく、変換後のCodex設定を再審査できるかで決まります。CLAUDE.md と AGENTS.md、settings.json と config.toml、slash commandsとSkills、subagentsとCodex agentsは、対応関係があっても同一ではありません。

初回はautomatic updatesを切り、MCPとhooksを無効またはread-onlyへ寄せ、差分確認後に1つずつ戻してください。設定移行を作業継続の近道にしつつ、過去の権限や例外まで自動で正当化しないことが重要です。

参考資料

WRITTEN BY nidoneko

Full-stack engineer with 8+ years of experience in TypeScript, React, Node.js, and cloud-native development across healthcare, finance, HR, and IoT domains.

View Profile →