一、为什么/import值得关注在同时使用 Cursor、Claude Code 和 Codex 的过程中最麻烦的往往不是切换工具而是重复迁移这些内容项目开发规范构建、测试和 Lint 命令自定义技能与命令MCP 服务配置Hooks 与自动化脚本项目目录和近期会话。根据 OpenAI 2026 年 8 月的更新ChatGPT 桌面端已经可以导入 Claude Code、Claude Cowork 或 Cursor 的部分配置Codex CLI 则支持从 Claude Code 或 Cursor 导入。官方说明指出CLI 中可以直接执行/import并选择需要导入的设置、项目文件及近期会话。查看官方更新说明不过导入功能解决的是“搬过来”不是“保证原样可用”。Cursor、Claude Code 和 Codex 对指令文件、权限、变量、Hooks、MCP 认证以及项目路径的处理方式并不完全相同。最典型的问题是配置看起来已经迁移但第一次运行任务时才发现命令失效、路径错误甚至把不该交给代理读取的环境变量一起带了过来。因此建议将迁移拆成四个阶段建立基线 → 执行导入 → 审计差异 → 运行验收二、先确认/import的适用范围在本地启动 Codex CLI然后输入/import接下来选择来源Select an agent to import from: Cursor Claude Code再选择需要迁移的项目、设置或聊天记录。按照官方导入文档Codex CLI 可以导入最多 50 条最近 30 天内的聊天记录但以下场景不能使用/importCodex 正在执行任务当前是远程会话CLI 已连接本地 app-server daemon。导入流程不会删除原来的代理配置但这并不意味着导入结果不存在覆盖、冲突或行为变化。官方也明确建议检查工具权限、MCP 认证、Hooks、参数占位符和文件路径。三、风险一导入前没有建立配置基线如果直接执行/import之后发现行为异常很难判断具体是哪个文件发生了变化。对于已经纳入 Git 管理的项目可以先记录当前状态gitstatus--shortgitdiff--statgitrev-parse --show-toplevel如果项目尚未使用 Git可建立一个临时审计仓库gitinitgitadd.gitcommit-mbaseline before codex import注意执行git add .前应先确认.gitignore已经排除.env、私钥和本地认证文件。建议的.gitignore至少包含.env .env.* *.pem *.key *.p12 auth.json credentials.json node_modules/ dist/完成导入后再次运行gitstatus--shortgitdiff--statgitdiff示例输出M AGENTS.md ?? .codex/config.toml ?? .agents/skills/review/SKILL.md这时先不要急着让 Codex 修改业务代码。应逐个确认新文件的来源、作用范围和是否需要进入版本库。如果导入内容位于用户级配置目录没有出现在项目 Git 差异中还需要单独检查 Codex 的用户级配置。根据配置参考文档用户级配置通常位于~/.codex/config.toml项目级配置则可以放在.codex/config.toml。四、风险二旧工具的指令被机械转换导入功能可以把部分指令文件转换成AGENTS.md但不同工具的规则并非天然等价。例如原指令可能包含- Always run pnpm test - Read configuration from C:\Users\demo\project\.env.local - Use the deploy-production command after changes迁移后至少存在三个问题新环境不一定安装了pnpmWindows 绝对路径无法在 macOS 或 Linux 使用“修改后自动部署”不应该成为默认代理行为。可以先用下面的命令检查常见危险关键词grep-RniE\deploy|production|\\.env|secret|token|password|sudo|rm -rf|curl.*POST\AGENTS.md .codex .agents2/dev/nullWindows PowerShell 可使用Get-ChildItem-Recurse-File|Select-String-Patterndeploy|production|\.env|secret|token|password|sudo|rm -rf发现问题后应把宽泛规则改成有触发条件的规则。例如## Deployment - 默认不得执行生产环境部署。 - 只有用户明确指定目标环境并确认部署时才可以准备部署命令。 - 执行前必须显示目标、分支和待执行命令。 - 不得读取或输出 .env、令牌、Cookie 与私钥。AGENTS.md更适合保存项目结构、运行命令、代码规范和验收标准而不是塞入大量模糊要求。OpenAI 的Codex 最佳实践也建议保持规则简洁、准确并在不同目录使用更具体的项目规则。五、风险三配置中携带了敏感信息最需要重视的是 MCP、插件和脚本配置。以下配置绝对不应该直接提交到仓库{headers:{Authorization:Bearer sk-demo-not-a-real-key}}正确做法是把凭据改成环境变量引用{headers:{Authorization:Bearer ${SERVICE_API_TOKEN}}}可以建立一个不依赖第三方库的 Node.js 扫描脚本。新建scripts/audit-agent-config.mjsimportfsfromnode:fs;importpathfromnode:path;constrootsprocess.argv.slice(2);consttargetsroots.length?roots:[.];constfilePattern/(^|\/)(AGENTS\.md|config\.toml|settings\.json|SKILL\.md)$/i;constsecretPatterns[{name:OpenAI-style key,regex:/\bsk-[A-Za-z0-9_-]{16,}\b/g},{name:Bearer token,regex:/Bearer\s[A-Za-z0-9._~\/-]{12,}/gi,},{name:Hard-coded secret,regex:/(api[_-]?key|token|password)\s*[:]\s*[][^][]/gi,},{name:Private key,regex:/-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----/g,},];functionwalk(current,files[]){if(!fs.existsSync(current))returnfiles;conststatfs.statSync(current);if(stat.isFile()){files.push(current);returnfiles;}for(constentryoffs.readdirSync(current,{withFileTypes:true})){if([.git,node_modules,dist].includes(entry.name))continue;constnextpath.join(current,entry.name);if(entry.isDirectory()){walk(next,files);}elseif(filePattern.test(next.replaceAll(\\,/))){files.push(next);}}returnfiles;}letfindings0;for(constrootoftargets){for(constfileofwalk(root)){constcontentfs.readFileSync(file,utf8);for(constpatternofsecretPatterns){constmatchescontent.match(pattern.regex)??[];if(matches.length0){findingsmatches.length;console.log([RISK]${file}:${pattern.name});}}}}if(findings0){console.error(\nAudit failed:${findings}possible secret(s) found.);process.exit(1);}console.log(Audit passed: no obvious hard-coded secrets found.);执行nodescripts/audit-agent-config.mjs.安全配置的输出Audit passed: no obvious hard-coded secrets found.如果放入一段虚拟 Token输出应类似[RISK] .codex/config.toml: Bearer token Audit failed: 1 possible secret(s) found.这个脚本只能发现常见格式不能替代专业密钥扫描工具但很适合作为导入后的第一道检查。六、风险四绝对路径和旧命令已经失效很多个人配置会写死工作目录C:\Users\alice\Desktop\shop-api /Users/alice/dev/shop-api /home/alice/work/shop-api换设备、系统或用户名后这些路径就会失效。可以扫描常见绝对路径grep-RniE\([A-Za-z]:\\Users\\|/Users/|/home/)\AGENTS.md .codex .agents2/dev/null推荐改成相对路径- 后端代码位于 ./server - 前端代码位于 ./web - 在仓库根目录执行测试还应验证规则中引用的命令是否真实存在command-vnodecommand-vnpmcommand-vpnpmcommand-vpython以及检查package.json中的脚本node-e const p require(./package.json); console.table(p.scripts || {}); 示例输出┌─────────┬──────────────────────────┐ │ (index) │ Values │ ├─────────┼──────────────────────────┤ │ test │ node --test │ │ lint │ eslint . │ │ build │ vite build │ └─────────┴──────────────────────────┘如果AGENTS.md要求运行npm run typecheck而项目根本没有这个脚本就应该在启用代理任务前修正。七、风险五自动同步会重新带回旧配置ChatGPT 桌面端支持为导入内容开启自动更新。这个功能适合仍在两套工具之间切换的开发者但也意味着你刚刚手动修正的规则可能在下一次同步时再次发生变化。团队项目不建议把个人工具的配置直接当作唯一规则源。更稳妥的方式是团队共用规范放入仓库级AGENTS.md个人偏好保留在用户级配置密钥只通过环境变量或系统凭据管理器提供自动同步后再次运行审计脚本生产部署规则由 CI/CD 权限控制而不是只靠提示词约束。如果日常使用 ChatGPT Plus、Codex 或其他 AI 编程工具时遇到国内支付方式不便也可以通过第三方 AI 会员充值平台 gpt985了解可选服务。使用第三方平台前仍应自行核对服务范围、账号要求和风险说明不要把账号密码、API Key 或项目密钥交给无关页面。八、风险六只检查配置没有进行行为验收配置文件没有明显问题不代表 Codex 会按预期工作。建议准备一个不会修改生产代码的验收任务请先阅读当前项目适用的 AGENTS.md 和配置文件不修改任何文件。 完成以下检查 1. 输出项目根目录 2. 列出你识别到的构建、测试与 Lint 命令 3. 说明当前允许修改和禁止修改的目录 4. 指出规则中的无效路径、缺失命令和冲突要求 5. 不读取 .env不执行部署不安装依赖。理想输出应该包含项目根目录/workspace/shop-api 可用命令 - npm test - npm run lint - npm run build 发现问题 - AGENTS.md 引用了不存在的 npm run typecheck - 部署脚本缺少环境限制 - 未读取 .env - 未修改任何文件最后再运行项目自身检查npmtestnpmrun lintnpmrun buildgitstatus--short验收目标如下检查项通过标准常见异常导入差异所有新增文件均可解释出现未知脚本或配置敏感信息无明文令牌、密码、私钥MCP Header 写死 Token指令文件命令和目录真实存在沿用旧设备绝对路径权限范围默认不碰生产环境自动执行部署、推送项目测试测试、Lint、构建通过规则引用不存在的命令工作区状态只有预期修改导入后业务文件被改动九、推荐的完整迁移流程下面是一套更稳妥的执行顺序# 1. 确认当前项目gitrev-parse --show-toplevelgitstatus--short# 2. 建立导入前基线gitaddAGENTS.md .codex .agents2/dev/nullgitcommit-mchore: snapshot agent setup before import# 3. 在 Codex CLI 中执行# /import# 4. 检查变化gitstatus--shortgitdiff# 5. 扫描敏感内容nodescripts/audit-agent-config.mjs.# 6. 验证项目命令npmtestnpmrun lintnpmrun build# 7. 检查最终状态gitstatus--short如果不希望提交临时基线也可以使用独立分支gitswitch-cchore/codex-import-audit确认导入结果无误后再把需要的配置合并回正式开发分支。十、结论/import的价值不是让开发者“换一个 AI 工具重新开始”而是尽量保留原来的工作上下文。但迁移的重点不应该停留在“能不能导入”而应该落到以下六项是否建立了导入前基线指令转换后是否仍然符合项目实际配置中是否存在敏感信息路径和命令是否在新环境中有效自动同步是否会覆盖人工修正是否完成了只读检查与项目验收。最安全的判断标准只有一句话导入完成只是迁移开始审计通过才代表配置可以使用。
