一、为什么 /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 天内的聊天记录，但以下场景不能使用 /import：

• Codex 正在执行任务；
• 当前是远程会话；
• CLI 已连接本地 app-server daemon。

导入流程不会删除原来的代理配置，但这并不意味着导入结果不存在覆盖、冲突或行为变化。官方也明确建议检查工具权限、MCP 认证、Hooks、参数占位符和文件路径。

三、风险一：导入前没有建立配置基线

如果直接执行 /import，之后发现行为异常，很难判断具体是哪个文件发生了变化。

对于已经纳入 Git 管理的项目，可以先记录当前状态：

git status --short
git diff --stat
git rev-parse --show-toplevel

如果项目尚未使用 Git，可建立一个临时审计仓库：

git init
git add .
git commit -m "baseline before codex import"

注意：执行 git add . 前，应先确认 .gitignore 已经排除 .env、私钥和本地认证文件。

建议的 .gitignore 至少包含：

.env
.env.*
*.pem
*.key
*.p12
auth.json
credentials.json
node_modules/
dist/

完成导入后再次运行：

git status --short
git diff --stat
git diff

示例输出：

 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

迁移后至少存在三个问题：

1. 新环境不一定安装了 pnpm；
2. Windows 绝对路径无法在 macOS 或 Linux 使用；
3. “修改后自动部署”不应该成为默认代理行为。

可以先用下面的命令检查常见危险关键词：

grep -RniE \
  "deploy|production|\\.env|secret|token|password|sudo|rm -rf|curl.*POST" \
  AGENTS.md .codex .agents 2>/dev/null

Windows PowerShell 可使用：

Get-ChildItem -Recurse -File |
  Select-String -Pattern "deploy|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.mjs：

import fs from "node:fs";
import path from "node:path";

const roots = process.argv.slice(2);
const targets = roots.length ? roots : ["."];

const filePattern =
  /(^|\/)(AGENTS\.md|config\.toml|settings\.json|SKILL\.md)$/i;

const secretPatterns = [
  { 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,
  },
];

function walk(current, files = []) {
  if (!fs.existsSync(current)) return files;

  const stat = fs.statSync(current);
  if (stat.isFile()) {
    files.push(current);
    return files;
  }

  for (const entry of fs.readdirSync(current, { withFileTypes: true })) {
    if ([".git", "node_modules", "dist"].includes(entry.name)) continue;

    const next = path.join(current, entry.name);
    if (entry.isDirectory()) {
      walk(next, files);
    } else if (filePattern.test(next.replaceAll("\\", "/"))) {
      files.push(next);
    }
  }

  return files;
}

let findings = 0;

for (const root of targets) {
  for (const file of walk(root)) {
    const content = fs.readFileSync(file, "utf8");

    for (const pattern of secretPatterns) {
      const matches = content.match(pattern.regex) ?? [];
      if (matches.length > 0) {
        findings += matches.length;
        console.log(`[RISK] ${file}: ${pattern.name}`);
      }
    }
  }
}

if (findings > 0) {
  console.error(`\nAudit failed: ${findings} possible secret(s) found.`);
  process.exit(1);
}

console.log("Audit passed: no obvious hard-coded secrets found.");

执行：

node scripts/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 .agents 2>/dev/null

推荐改成相对路径：

- 后端代码位于 `./server`
- 前端代码位于 `./web`
- 在仓库根目录执行测试

还应验证规则中引用的命令是否真实存在：

command -v node
command -v npm
command -v pnpm
command -v python

以及检查 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
- 未修改任何文件

最后再运行项目自身检查：

npm test
npm run lint
npm run build
git status --short

验收目标如下：

检查项	通过标准	常见异常
导入差异	所有新增文件均可解释	出现未知脚本或配置
敏感信息	无明文令牌、密码、私钥	MCP Header 写死 Token
指令文件	命令和目录真实存在	沿用旧设备绝对路径
权限范围	默认不碰生产环境	自动执行部署、推送
项目测试	测试、Lint、构建通过	规则引用不存在的命令
工作区状态	只有预期修改	导入后业务文件被改动

九、推荐的完整迁移流程

下面是一套更稳妥的执行顺序：

# 1. 确认当前项目
git rev-parse --show-toplevel
git status --short

# 2. 建立导入前基线
git add AGENTS.md .codex .agents 2>/dev/null
git commit -m "chore: snapshot agent setup before import"

# 3. 在 Codex CLI 中执行
# /import

# 4. 检查变化
git status --short
git diff

# 5. 扫描敏感内容
node scripts/audit-agent-config.mjs .

# 6. 验证项目命令
npm test
npm run lint
npm run build

# 7. 检查最终状态
git status --short

如果不希望提交临时基线，也可以使用独立分支：

git switch -c chore/codex-import-audit

确认导入结果无误后，再把需要的配置合并回正式开发分支。

十、结论

/import 的价值不是让开发者“换一个 AI 工具重新开始”，而是尽量保留原来的工作上下文。

但迁移的重点不应该停留在“能不能导入”，而应该落到以下六项：

1. 是否建立了导入前基线；
2. 指令转换后是否仍然符合项目实际；
3. 配置中是否存在敏感信息；
4. 路径和命令是否在新环境中有效；
5. 自动同步是否会覆盖人工修正；
6. 是否完成了只读检查与项目验收。

最安全的判断标准只有一句话：

导入完成只是迁移开始，审计通过才代表配置可以使用。