前言¶

在 DeepSeek Harness（DSH）里，单会话往往只能串行处理一件事：派一个子任务就要等它跑完，或者自己切窗口盯着另一条会话。若希望「当前会话继续写代码、另一条会话在后台读文档并回信」，又要在子会话提权时由创建者把关，就需要宿主之外的编排能力。

dsh-cross-session-approval 是社区维护的工作流类 bundle（维护者 zsjs110110-cpu，当前 README 版本 0.3.10），面向 DSH 0.2.x（peer 依赖 >=0.2.0-rc.2 <0.3.0）。它在同一宿主内提供十个跨会话工具、派活登记、cs_ 短别名寻址、子会话权限夹紧，以及把子会话沙箱提权审批转给创建者会话的审批桥。插件以 npm 包 dsh-cross-session-approval 发布，MIT 许可证；社区目录页见 SkillHub，源码与说明见 GitHub。

这是什么¶

一句话：在已配置的 DSH profile 里加载后，智能体可通过工具创建顶层持久会话、投递任务与消息、读状态与消息尾、批量广播、改名归档，并在子会话需要提权时由 spawn 的创建者调用 cross_session_approve 做决定。

它不是独立运行的 MCP 服务，而是随宿主进程加载的 bundle；工具调用发生在 DSH 会话内，不是可直接在 shell 里执行的 PowerShell 命令。

派活元数据写在当前工作区下的 .cross-session/registry.json（可通过 cordis.patch.yml 的 stateDir 调整目录名），采用临时文件加原子重命名写入。登记表含任务正文与回复摘要，可能敏感，应仅作工作区本地数据保管。读取失败会阻断依赖登记的操作；写入失败会告警，已完成的投递不会因此撤回。

核心功能¶

十个跨会话工具¶

单条任务或消息正文按 32 KiB UTF-8 截断；登记表最多保留 200 条记录，超出时淘汰最久未活动的项。登记表不是完整会话历史。

cs_ 短别名¶

部分显示链路会把长会话 ID 替换成占位符，从界面复制占位符无法寻址。插件用 FNV-1a 派生 cs_ 加 10 位 base62 的别名（总长 13，例如 cs_xwx698M4Wa）。cross_session_list 与 cross_session_status 会返回 alias；工具参数名仍为 session_id、to 或 reply_to。别名用于寻址，不是授权凭据。

子会话权限夹紧（A / F）¶

默认 spawnPermission: cap：在 cross_session_spawn 创建时，沙箱档位、审批策略与工作区不能宽于调用者（省略 permission 时与部署默认取较窄/更严组合）。可选 agent_preset 指定宿主自定义模式 ID，默认继承调用者；cwd 默认调用者工作区根，非最高档调用者不能指到工作区外。

默认 forkPermission: cap：对带 parentSession 的派生创建做类似收窄；strict 在源会话未加载时直接拒绝。开审批桥要求 spawnPermission 为 cap，不能为 off。

跨会话审批桥¶

由 cross_session_spawn 创建的任务会话，在 pwsh 或 run_code 请求沙箱提权时，可把审批交给创建者会话（owner）。owner 须在同一宿主中保持活跃；本版不会为审批恢复未加载的 owner。所有者只在 spawn 时写入内存，重启后不持久化，旧任务回落本地 UI 审批。

owner 收到通知后，用形如 apv_XXXXXXXXXXXX 的 key 调用 cross_session_approve（与审计用 approval/asked ID 不同）。仅请求会话的创建者可处理；危险规则命中或无法判定时强制拒绝，owner 无权放行。

安装与启用¶

需要 Node.js 18+，以及已配置可用模型的 DSH 0.2.x profile。以下以 profile 名 dev 为例，请替换为实际名称。

方式一（npm，README 推荐）：在 profile 目录安装，npm 会解析 @deepseek-ai/* peer 依赖。

$profileDir = Join-Path $HOME ".dsh/profiles/dev"
cd $profileDir
npm install dsh-cross-session-approval@0.3.10

方式二（GitHub Release tarball）：适用于 dsh plugin 安装及 awesome-dsh-plugin 市场目录。

dsh plugin --profile dev add "https://github.com/zsjs110110-cpu/dsh-cross-session-approval/releases/latest/download/dsh-cross-session-approval.tgz"

方式三（源码）：需具备仓库读取权限；将仓库放到 profile 的 node_modules/dsh-cross-session-approval，并在该 profile 的 package.json 里把包名追加到 dsh.profile.bundles：

{
  "dsh": {
    "profile": {
      "bundles": ["dsh-cross-session-approval"]
    }
  }
}

校验并启动：

dsh --profile dev --dump-config
dsh --profile dev --no-open --port 0

配置输出应包含 cross-session-approval 且无该 bundle 的 skipping；启动时不应出现该插件的 failed to import。进入会话后确认工具列表含上述十项。配置成功不代表审批桥已按预期启用，还需对照启动告警与 cordis.patch.yml 中 approvalBridge.enabled 等项。

审批桥相关配置片段（完整项见仓库 cordis.patch.yml）：

config:
  stateDir: .cross-session
  spawnPermission: cap
  forkPermission: cap
  approvalBridge:
    enabled: true
    timeoutMs: 300000

典型用法¶

下列为 DSH 会话内的工具调用示例，cs_XXXXXXXXXX 须替换为 spawn 实际返回的别名。

cross_session_spawn({ name: "检查文档", task: "阅读 README，列出安装步骤中的歧义；完成后回复结果。" })
cross_session_status({ session_id: "cs_XXXXXXXXXX" })
cross_session_read({ session_id: "cs_XXXXXXXXXX", tail: 10 })
cross_session_send({ session_id: "cs_XXXXXXXXXX", message: "请再核对配置示例。", interrupt: false })

spawn 会在任务消息中附上回信目标；任务会话完成后应调用：

cross_session_reply({ to: "<回信目标别名>", text: "结果摘要或失败原因" })

投递成功与任务完成是两种状态，需结合回信与 read 判断。建议初次使用不传 permission 和 cwd，沿用默认夹紧与当前工作区。

审批示例：

cross_session_approve({ key: "apv_XXXXXXXXXXXX", decision: "allow", note: "已核对任务与提权范围" })
cross_session_approve({ key: "apv_XXXXXXXXXXXX", decision: "reject" })

适用场景与注意¶

适合需要在 DSH 0.2.x 内做多会话编排的开发者：后台派活、主会话继续交互、子会话结果通过 reply 回流，以及由创建者集中处理子会话提权审批。

安装前请自行查看 GitHub 仓库 源码与 MIT 许可证。插件随当前 DSH 进程与 profile 权限运行，登记表落盘内容可能含任务细节；跨工作区寻址、显式权限与审批桥限制以 README 为准。SkillHub 等社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系。

结尾¶

dsh-cross-session-approval 把跨会话 spawn、消息、状态查询与审批桥收进一个 0.2.x bundle，并用 cs_ 别名缓解长 ID 被遮蔽带来的寻址问题。若要安装或查版本细节，可从 SkillHub 插件页 进入，或直接打开 GitHub 仓库 README。