前言¶

如果你同时维护 Codex 和 DeepSeek Harness（DSH）两套智能体环境，配置迁移时的问题通常不是缺工具，而是看不清：Codex 的 config.toml、hooks、Skills 和 AGENTS.md 散落在用户级、项目级多个位置，哪些能被 DSH 直接对应使用、哪些属于不支持项，只能逐个手工核对。直接照搬又有风险——两边的权限语义不同，hooks 的支持范围也不一致。

dsh-codex-import 把这一步单独拆出来：先做只读盘点，再给出分类结果，v0.1 不执行任何迁移。DSH 的理念是「一切皆插件」，这个插件对应的正是迁移前的核对环节。

这是什么¶

dsh-codex-import 是 DeepSeek Harness 的 Codex 配置兼容性扫描器，由 QinXi-ai 维护，采用 MIT 许可证，当前版本 0.1.0。一句话定位：v0.1 只提供只读盘点，不执行迁移。

安装后，插件通过 dsh.bundle.patch 指向 cordis.patch.yml，向已有的 commands 服务注册 /codex-import 命令，复用 DSH 现有的命令服务。

核心功能¶

插件提供两个命令：

/codex-import scan
/codex-import plan

两个命令都处于只读范围内，不写文件、不执行迁移。

扫描范围与分类¶

扫描器会发现四类 Codex 侧配置：

• 用户级和项目级 config.toml
• hooks.json
• 独立 Skills
• AGENTS.md 指令层

结果分为五类：READY、DISCOVERED、NEEDS_REVIEW、SKIPPED_UNSUPPORTED、UNSUPPORTED。

扫描器同时识别当前 DSH hooks-codex 桥接可运行的五类同步 command hooks：PreToolUse、PostToolUse、SessionStart、UserPromptSubmit、Stop。超出这个范围的 hooks 条目不会被视为可在当前桥接下运行。

输出经结构化收缩¶

扫描器会读取受大小限制的本地配置用于分类，但输出经过结构化收缩：只包含类别、状态、数量和通用原因，不返回配置值、命令正文、Skill 正文或绝对路径。

明确边界¶

v0.1 不提供 apply，具体包括：

• 不写任何文件，不修改 DSH profile。
• 不执行 hook command，不启动 MCP server。
• 不复制或安装 Skill。
• 不读取聊天历史。
• 不导入、输出或保存 credential 值。
• 不把 Codex 权限规则自动翻译成 DSH 权限——两者安全语义不同。

对兼容性也不做超出事实的声称：

• 不声称完整兼容 Codex Hooks。当前 DSH 桥接只映射上面列出的五类，且只运行同步 command hooks。
• 只识别标准的 AGENTS.override.md / AGENTS.md 文件名，不解析 project_doc_fallback_filenames 指定的自定义指令文件名。
• 为避免扫描逃逸，不跟随符号链接和非普通文件，符号链接条目标为 SKIPPED_UNSUPPORTED。这比 Codex 原生 Skill 发现更保守。

关于后续新增显式 apply，README 给出了准入门槛：版本化新输出目录、逐项选择、写前 diff、凭据引用而非凭据值、每项迁移收据、语法验证，以及任何不支持项 fail closed。v0.1 故意没有预留静默写入入口。

安装与启用¶

package.json 的 engines 要求 Node >= 22.19，peerDependencies 为 @deepseek-ai/cordis >=4.0.1 <5 和 @deepseek-ai/dsh-commands >=0.1.0-rc.2 <0.2.0。

安装方式是先把插件放到包管理器可达的位置——将目录放入 GitHub 仓库并添加 dsh-plugin topic，或发布到 npm——再添加到目标 profile：

dsh plugin --profile web add dsh-codex-import

开发中的目录也可以用包管理器支持的本地 package spec 安装。

典型用法¶

装好后，在 DSH 会话里直接调用两个命令，即可得到分类盘点结果：

/codex-import scan
/codex-import plan

本地开发或审计时，可用 README 给出的三条命令验证：

npm test
npm run check
npm pack --dry-run

npm test 运行 node --test；npm run check 先依次对 src/scanner.js、src/format.js、src/index.js 做语法检查，再跑一遍测试；npm pack --dry-run 检查实际打包内容。测试只使用临时人工夹具，不会扫描开发者真实的 Codex 配置。

适用场景与注意¶

适合两类人：

• 正在评估从 Codex 迁到 DSH，想知道现有配置里多少能对应、多少需要人工处理，又不想在评估阶段产生任何副作用的开发者。
• 想先摸清 Codex 侧配置分布，再决定迁移策略的使用者。

使用前注意：

• 插件以当前 dsh 进程的权限运行，安装前应检查源码与许可证（本项目为 MIT）。
• v0.1 的定位是盘点，不是迁移工具。不要期待它翻译权限规则，也不要把它当作完整兼容 Codex Hooks 的依据。
• 符号链接条目会被标为 SKIPPED_UNSUPPORTED，这是有意为之的保守行为，不是缺陷。

小结¶

dsh-codex-import 把「Codex 配置能不能迁到 DSH」从手工核对变成一次可重复的只读扫描：五类分类结果、五类可桥接 hooks 的明确范围、收缩后的输出，加上一条条写清的「不做」清单。v0.1 不执行迁移，但后续 apply 的准入门槛已经写在 README 里，边界是可核对的。

• GitHub：https://github.com/QinXi-ai/dsh-codex-import
• 社区目录页：https://www.skillhub.cn/plugins/QinXi-ai/dsh-codex-import