dsh-native-codex-cli

3. 配置

配置走一个 JSON 文件（不是 cordis.patch.yml 里的 config:）：

~/.dsh/storages/dsh-native-codex-cli/config.json

{
  "codexBin": "codex",              // Codex 可执行文件；留在 PATH 上就用 codex
  "codexArgs": [],                  // 追加在 app-server 之后的参数
  "transport": "stdio",             // stdio（已实现）；daemon 为预留适配层
  "experimentalApi": true,          // 打开 app-server 实验性方法与字段
  "approvalPolicy": "on-request",   // 新建线程默认审批策略
  "sandbox": "workspace-write",     // 新建线程默认沙箱
  "model": "",                      // 新建线程默认模型；空 = 用 Codex 自己的默认
  "traceWire": false                // true 时把每一帧协议写进插件日志
}

文件不存在或写坏了都会退回代码里的默认值，绝不影响插件启动。

为什么不放在 patch 的 config: 里？ cordis 的 resolveConfig 会拿插件导出的 Config schema 去校验 patch 里的 config：

function resolveConfig(runtime, config) {
  if (!runtime.Config) return config
  const result = runtime.Config["~standard"].validate(config)   // ←
  ...
}

本插件没有 schema 库可用（pnpm 隔离布局下 @deepseek-ai/cordis 不可从插件包内解析）， 一旦导出普通对象当 Config、或在 patch 里提供 config，条目就会以 TypeError: Cannot read properties of undefined (reading 'validate') 激活失败， apply() 根本不会执行。这正是本插件第一次装进真实 DSH 时踩到的坑 （Config 检查器当时报的唯一异常状态 unsupported）。所以插件既不导出 Config， patch 里也不带 config，与两个可用的第三方插件保持一致。 若以后要恢复 loader 托管配置，导出符合 Standard Schema 的对象即可： export const Config = { '~standard': { version: 1, vendor: 'dsh-native-codex-cli', validate: (v) => ({ value: ... }) } }。

插件日志：~/.dsh/logs/dsh-native-codex-cli.log，也可以在浏览器里 GET /dsh-native-codex-cli/log 看最近 300 行。 客户端把关键诊断（Slot 注册、输入框 hook 形状）POST 到 /dsh-native-codex-cli/diag，同样落在这个文件里。

---